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FOREWORD 


The Software Enqlneering Laboratory (SEL) is an organization 
sponsored by the National Aeronautics and Space Administra** 
tion Goddard Space Plight Center dNASA/GSPC) and created for 
the purpose of investigating the effectiveness of software 
engineering technologies when applied to the development of 
applications software. The SEl was created in 1977 and has 
three primary organizational members: 

NASA/GSFC (Systems Development and Analysis Branch) 

The University of Maryland (Computer Sciences Department) 
Computer Sciences Corporation (PCASS Project) 

The goals of the SEL are (1) to understand the software de- 
velopment process in the GSFC environment; (2) to measure 
the effect of various methodologies, tools, and models on 
this process; and (3) to identify and then to apply success- 
ful development practices. The activities, findings, and 
recommendations of the SEL are recorded in the Software 
Engineering Laboratory Series, a continuing series of re- 
ports that includes this documenv A version of this docu- 
ment was also Issued as Computer Sciences Corporation 
document CSC/SD-83/6012. 

The primary contributors to this document include 

Pei-Shen Lo (Computer Sciences Corporation) 

David Wyckoff (Computer Sciences Corporation) 

Other contributors include 

Jerry Page (Computer Sciences Corporation) 

Frank McGarry (Goddard Space Flight Center) 

Single copies of this document can be obtained by writing to 

Prank E. McGarry 
Code *582.1 
NASA/GSFC 

Greenbelt, Md. 20771 
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ABSTRACT 


This document provides a description of the structure of the 
Software Engineering Laboratory (SEL) data base. It defines 
each data base file in detail and provides information about 
how to access and use the data for programmers and other 
users. Several data base reporting programs are described 
also . 
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SECTION 1 - INTRODUCTION 


The Software Engineering Laboratory (SEL) was created to 
support efforts to measure and evaluate the effects of var> 
ious methodologies# models# and tools on the software de- 
velopment process. The SEL is a combined effort involving 
Goddard Space Plight Center (GSPC) # Computer Sciences Cor- 
poration (CSC)# and the University of Maryland (UM) . 

One of the major functions of the SEL is the collection# 
analysis# and archiving of detailed data# describing all 
facets of the software development process within the Sys- 
tems Development Section of GSFC. The projects providing 
the detailed data are software development efforts in sup- 
port of GSFC flight dynamics ground support systems. 

To facilitate the use of the information collected# a data 
base was designed that consists of approximately 330 Indexed 
files on a DEC PDP-lI/70 computer. In addition to several 
header or summary files# each project studied may require up 
to 11 files--one for each of the 7 types of forms collected 
and 4 general information files. Section 2 of this document 
describes the structure of the data base. The software 
packages that support the entry# maintenance# reporting# re- 
trieving# and backup of this data base are described in Sec- 
tion 3. 
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SECTION 2 - DATA BASE ORGANIZATION 


This section describes the structure and content of the SEL 
data base files. Many of the files are organized in re- 
sponse to the structure of the SEL forms. In general, the 
files are organized by project and by form type. Exceptions 
and additions are noted in the following subsections. 

The following is a list of the data base files in the order 


in which they are described 

in Section 

2.2 and in Appendix A 

("proj” is the project name; 
in the data base) : 

•*n" is the 

number of projects 

Descriptive File Name 

Number 

of 

Files 

File Name 

Encoding Dictionary File 

1 

ENCODE. HDR 

Estimated Statistics Pile 

1 

EST.HDR 

File Name and Status File 

1 

STAT.HDR • 

Phase Dates File 

1 

HEADER. HDR 

Subjective Evaluations 
Directory File 

1 

DIR. HDR 

Subjective Evaluations 
File 

1 

SEP. HDR 

Attitude Maintenance 
Change Report (ATM) Pile 

n 

projl. ATM,proj 2. ATM, 
. . . ,prOjn.ATM 

Change Report Form (CRF) 
Pile 

n 

projl. CRF, proj 2. CRF, 
. . . ,projn.CRF 

Component Status Report 
(CSR) Pile 

n 

projl. CSR, proj 2. CSR, 
... ,pro3n.CSR 

Component Summary Form 
(CSP) File 

n 

projl. CSP, proj2.CSF 
. . . ,projn.CSF 

General Project Summary 
(GPS) Pile 

n 

projl. GPS, proj 2. GPS, 
. . . ,projn.GPS 

Resource Summary Form 
(RSP) Pile 

n 

projl. RSF, proj 2. RSP, 
. . . ,projn.RSF 
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Descriptive File Name 


Number 

of 

Piles File Name • 


Run Analysis Form (RAF) 
File 

Accounting Information 
(ACC) File 

Comment (CMT) File 


Component Information 
File (CIF) 

Growth History (HIS) 
File 

Source Analyzer Program 
(SAP) Output File 

Transaction (backup) 
Files 


2.1 FILE ATTRIBUTES 


n projl.RAF, proj2.RAF, 

. . . fprojn.RAF 

n projl.ACC,proj2.ACC, 

. . . rprojn.ACC 

n projl.CMT/proj2.CMT« 

. . . rprojn.CMT 

n projl.CIF,proj2.CIF» 

. . . iprojn.CIF 

n projl.HIS,proj2.HIS, 

. . . fprojn.HIS 

1 ALL. SAP 


7 TRANS. CIF, TRANS. CRF 

TRANS. CSR, TRANS. CSF 
TRANS. HIS, TRANS. RSF 
TRANS. RAF 


All data base files, except the transaction files, are 
located on disk DBl, under user identification code 
(UIC) [204,1]. The name of a file is composed by attaching 
the project name and form type abbreviation to the disk and 
UIC designation. For example, to access change report data 
for project PROJ, the name would be DBl: [204,1]PROJ.CRF. 


The transaction files are on disk DBO to allow data base 
restoration in the case of a failure of disk DBl. 


The larger projects have up to 2,000 forms and up to 
10,000 records. A project this large would take up about 
4000 500-byte blocks. The total data base takes up approx- 
imately 49,000 blocks. 
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2.2 FILE DESCRIPTIONS 

On this data base, there are three file types or categories: 

• Header or summary files 

• Form data files 

• Auxiliary files 

Header or summary files contain directory and summary infor- 
mation (such as total lines of source code, project dura- 
tion, ano total effort) for each project. 

Form data files correspond directly to a particular type of 
form; there is a separate file for each form type per proj- 
ect. 

Auxiliary files contain support information, such as de- 
scriptive text (Ccmnient Files) , taken from the software en- 
gineering forms and component descriptions generated by SAP 
(Reference 1) 

Except as noted, all files are indexed. Appendix A de- 
scribes all file formats in detail, including every field in 
each record type. 

2.2.1 HEADER (SUMMARY) FILES 

The header or summary files contain directory and summary 
information for the entire data base. These files can be 
used to obtain top-level summary reports on all the data. 

The following six header files are described in this section: 

• Encoding Dictionary 

• Estimated Statistics 

• File Name and Status 

• Phase Dates 

• Subjective Evaluations 

• Subjective Evaluations Directory 
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2 . 2 . 1 . 1 E.icodinq Dictionary Filt (ENCODE. HDR) 

The Encoding Dictionary File contains the numerical code 
type information used to represent the lengthier alpha- 
numeric or English text information. The codes are used to 
save space where certain titles# names# or other pieces of 
information are used repetitively throughout the data base. 
Twenty-four different types of codes are represented on the 
file. (Some types may require more than one record of 
data.) Typical pieces of data that are coded and placed on 
this dictionary are project name# programmer name# source 
language# types of changes# and types of error. Thus# since 
project names# for example# are used repetitively throughout 
the data base# the corresponding numerical codes are used 
instead of the full name. The codes are assigned by the 
data base administrator and do not have any particular sig- 
nificance as far as priority or importance are concetxied. 

The Encoding Dictionary File contains the following fields: 

e Code type 

e Code 

• Abbreviated name 

e Full English description 


Below are three sample records: 


Type Code Abbreviation 


4 

4 

4 


1 

2 

3 


UN ITT 

SYSTEMT 

BNCHMRKT 


Description 

Unit test 
System test 
Benchmark test 


See Appendix A# Section A.l# for the file formitt. 


^Throughout Section 2# each of the records is to be read 
across. For example# on page 2-7# the first or Project 1 
record contains a code of 10, 638 components, 535 modules, 
and so on. 
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2. 2. 1.2 Estlmafd Statlitici Filt (EST.HDR) 


Th« Batlmatad statlstici Fila charactarlzas the size and 
resources (manpowerf computer) of each project. The Hi a 
contains a single record of information for each project on 
the data base. Each record contains a project name as well 
as information summarizing the characteristics of that proj> 
ect. This information is usually collected at the conclu- 
sion of a project by personnel close to the project. It 
summarHts the basic size and resource characteristics of 
each project. The project managers review the completed 
project and gather the following information for this filet 

e Project name 

e Number of components and modules 

e Number of lines, executable statements, runs, and 
changes 

e Number of pages of documentation 

» fc 

e Programmer, management, and services hours 

e IBM S/360-95 and -75 hours {based on computer 
accounting information) 

e Other computer hours 

Below are three sample records--one for Project 1, one for 
Project 2, and one for Project 3--in the Estimated Sta- 
tistics File. The programmer, management, and services 
hours are stored as integer type characters formed from the 
real number values times 10. The status flag^ refers to 
the status of the data: 1 is unchecked data, 2 is hand- 

checked data, and 3 is data verified by application. 


T 


This is true for all sample records throughout Section 


2 . 
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Project 

Name 

r»roject 

Code 

Number of 
Components 

Total 
Number of 
Modules 

Number 
of New 
Modules 

PROJl 

10 

638 

535 

337 

PROJ2 

38 

113 

102 

93 

PR0J3 

19 

639 

519 

418 

Number of 
Modified 

Number 

Number of 

Pages of 

Total 

Number 

Modules 

of Runs 

Changes 

Document 

of Lines 

31 

7500 

1576 

1793 

75,393 

0 

1589 

255 

763 

15,258 

59 

1000 

2350 

2458 

85,369 


Number of 

Number of 

Number of 

Number of 
Modified 

Number of 

Modified 

Total Exec 

New Exec 

Exec 

New Lines 

Lines 

Statements 

Statements 

Statements 

49,3ie 

4252 

30,448 

»9,098 

1179 

14,873 

0 

« 4,482 

4,413 

0 

76,883 

5652 

38,157 

35,203 

2161 

Programmer 

Management Services 

S/360-95 

Hours 

Hours 

Hours Computer Hours 

109,565 

35,510 

12 

,310 

2090 

3.1,638 

13,022 

11 

,942 

628 

115,586 

27,119 

27 

,444 

3120 

S/360-75 

Other S 

tatus Active 

Project 

Computer Hours Computer Hours 

Flag Flag 

Category 

1930 

0 


1 N 

1 

4 

0 


1 N 

X 

1852 

0 


1 N 

1 

See Appendix 

A, Section 

A. 2, for the file format. 
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2. 2. 1.3 File Name and Status File (STAT.HDR) 

The File Name and Status File is a type of summary directory 
for the entire data base. It contains one record for each 
indexed file in the data base. Each record contains a file 
name; creation, last backup, and last access dates (YYMMDD 
format) ; and number of records in the particular file. 

These data are updated automatically by the data entry pro- 
gram (Data Base Maintenance Software (DBAM) (Reference 2)) 
whenever a file is accessed. 


Three sample File Name and Status File records are given 
below--one for Project 1, one for Project 2, and one for 
Project 3: 


Project 

Name 

Project 

Code 

Pile Name 

Creation 

Date 

PROJl 

10 

DBl: {204,1] PROJl. RSF 

790312 

PROJ2 

38 

DBl: [204,1] PROJ2. RSF 

791026 

PROJ3 

19 

DBl: [204,1] PROJ3. RSF 

790901 


Last Backup 

Last Update Number 

of 


Date Date Records 


820611 790312 91 

820611 0 93 


820611 


0 


162 


See Appendix A, Section A. 3, for the file format. 


2. 2.1.4 Phase Dates File (HEADER. HDR) 

The Phase Dates File contains the start and end dates for 
all phases in the software development cycle. The file in- 
cludes project name, code, and the dates (YYMMDD format) for 
the requirements, design, code and unit test, system test, 
acceptance test, cleanup, and maintenance phases for each 
project. These dates are obtained from the project manager 
at the conclusion of each project. 


2-7 


8070 



Below are three sample Phase Dates File records->one for 
Project 4, one for Project 2 , and one for Project 3: 


Project 

Name 

Project 

Code 

Development 

Computer 

Target 
Computv r 

Alien 

Computer 

Use 

PROJ4 

2 

0 

0 

0 

PROJ2 

10 

0 

0 

0 

PROJ3 

19 

0 

0 

0 

Req. 

Req. 

Design 

Design 

Code and 

Start 

End 

Start 

End Test Start 

761010 

770213 

770213 

770604 

770604 

770101 

770401 

770401 

770730 

770730 

780101 

780501 

780501 

781014 

781014 


System 

System Acceptance 

Acceptance 

Code and 

Test 

Test 

Test 

Test 

Test End 

Start 

End 

Start 

End 

771203 

771203, 

780204 

780204 

780318 

780114 

780114 

780218 

780218 

780415 

790331 

790331 

790602 

790602 

791013 

Cleanup 

Cleanup 

Maintenance 

Maintenance Status 

Start 

End 

Start 

End 

Flag 

780318 

780427 

780429 

780820 

1 

780415 

780624 

780624 

781024 

1 

791013 

791222 

791222 

800404 

1 

See Appendix A, Section 

A. 4, for the 

file format 

• 

2. 2.1. 5 Subjective Evaluations Pile 

(SEF.HDR) 



The Subjective Evaluations File characterizes the develop- 
ment methods and environment of each project. New informa- 
tion is added to this file near the conclusion of each 
project. By reviewing code and documents and by observing 
the development process, project managers quantify the de- 
gree to which each of the qualities applies to the project. 
This is strictly a subjective management evaluation. 
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TIu* diitn for «»ac'h project ore contained in seven v.iriable- 
lenoth records. Each record represents a main category of 
measures. The seven categories are 

• Software Engineering (SE) •'Includes practices and 
techniques (MT) , tools (TS) # and documentation (DC) 
rteaaurea 

• Development Tcvini Ability (AB) •-Includes experience 
with application (AP) , effectiveness of management 
(MC) , and performance of team (PF) measures 

• Difficulty of Project (DP) --Includes complexity of 
problem \CP) , internal Influences on project (IN), 
and external influences on project (EX) measures 

• Process and Product Characteristics (PC) --IneludeG 
resources available (RA) , software product (PR) , 
and product/proceas performance (PP) measures 

• Development Team Background (DB) --Includes team 
rank (RK) , years of professional experience (YP) , 
years of applicable experience (YA) , and years of 
envirunment experience (YE) measures 

• Models (MD) --Includes Wal& ton-Pelix model (WP) , 
PRICE S3 model (PS) , and COCOMO model (CO) measucoa 

• Additional Details (AD) -- Includes miscellaneous 
(MS) and code breakdown (SW) measures 

See Appendix A, Section A. 5, for the file format. Sample 
recorvis are not presented here because of their extreme 
length. Reference 3 describes the data collected for this 
file. 

-.3.1.6 Subjective Evaluations Directory File (DIR.HDR) 

The Subjective Evaliuations Directory Pile contains the 
alphanumeric code type information used to represent the 
lengthier English text inf orm»it ion. The codes represent 


3 “') 


{U170 



cei'tain titles, names, or other pieces of information de- 
scribing measures used in the Subjective Evaluations File. 
Each record contains information for one specified measure 
in the Subjective Evaluations File. The Subjectivr, Evalua- 
tions Directory File contains the following fields: 

• Code for the measure 

• Name of the measure 

• Minimum value of the measure 

• Maximum value of the measure 

• Data record sequence number (1 through 7) 

• Byte location in the data record 

• Textual description of the measure 

The following are three sample records: 


Code 

Name 

Minimum 

Value 

Maximum 

Value 

Record 

Number 

Byte 

Location 

Oescr ipt ion 

APOl 

EXPERTl 

* 0 

50 

2 

6 

Expert 1 

MT20 

CCONFIG 

0 

50 

1 

44 

Code (con- 
figuration 
control) 

SW61 

SCHANGEN 

0 

9000 

7 

472 

Software 

Changes 

(new) 

See Appendix A, 

Section 

A. 6, for 

the file 

format. 



2.2.2 FORM DATA PILES 

These files correspond in number and in content to the in- 
formation collected on the software engineering forms. 

There is one file for each form type per project. There are 
seven form data files, which are described in detail in the 
following subsections: 

1. Attitude Maintenance Change Report (ATM) Pile 

2. Change Report Form (CRF) Pile 

3. Component Status Report (CSR) Pile 

4. Component Summary Form (CSP) Pile 
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5. General Project Summary (GPS) B'ile 
o. Resource Summary Form (RSP) Pile 
7. Run Analysis Form (RAF) Pile 

2. 2. 2.1 Attitude Maintenance Change Report (ATM) File 

The Attitude Maintenance Change Report Pile contains in- 
formation on changes made to a program during the mainte- 
nance and operation phase of the project (after the project 
delivery date). The ATM form is filled out by maintenance 
personnel. Although this file contains essentially the same 
information provided on the Change Report Form, there are 
some slight differences. The following information can be 
found on the ATM File; 

• Programmer 

e Number of components changed 

• Date on which change was determined 

• Date on which change was started 

• Type of change 

• Primary erroi type 

• Types of error detection activities 

• Time spent implementing change 

See Appendix A, Section A. 7, for the file format. 

2 . 2 . 2 . 2 Change Report Form (CRF) File 

The Change Report Form File contains information on changes 
made by a programmer after the source has been added to the 
permanent library. The CRF is filled out by the programmer. 
Each form describes one error or change. One record on the 
CRF Pile represents one form and contains the following: 

• Programmer 

• Form date 

• Number of components changed 

• Number of components examined 
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• Dat« on which change was determined 

e Date on which change started 

e Amount of time/effort required for change 

• Type of change 

e Type of error (if error) 

e When error entered system 

e Activities used to isolate error 

e Time required to isolate error 

e Whether or not a workaround was used 

e whether or not change was related to a previous 

change 

Below are three sample records on the CRF Pile. Hyphens in- 
dicate blanks. 


Form 

Number 

Proiect 

Proqrammer 

Form 

Date 

Number of 
Components 
Chanqed 

K00016 

19 

26543 

790103 

9 

K00017 

19 

14336 

781026 

1 

K00018 

19 

14336 

781026 

1 

Number of 
Components 
Examined 

More Than 
One Comp 
Affected 

Date 

Change Was 
Determined 

Date 

Change Was 
Started 

Effort 

for 

Chanqe 

11 

Y 

790102 

790102 

2 

1 

- 

781026 

781026 

2 

1 

- 

781026 

781026 

1 


Type of 
Change 
12 3 4 

Changed 
1 2 

Components 
3 4 5 

Type of 
Error 
12 3 4 

When Error 
Entered 
System 

1 4 - - 

443 386 

907 

881 

252 

3 

3 

1 

695 - 

- 

- 

- 

7 - - - 

- 

1 

152 - 

- 

- 


7 8 - - 

4 
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Data 

Structure 

Error 


X 


Control 
Logic 
Er ror 


X 


The following fields describe activities used to isolate 
errors. 


For 

Program 
Validation 
1 2 3 4 5 

1 4 - - - 
l 5 - - - 


For 

Detecting 
Symptoms 
1 2 3 4 5 

1 4 - - - 

1 

5 - - - - 


Tried in 
Finding 
Cause 
1 2 3 4 5 

5 6 B - - 


For 

Finding 
Cause 
1 2 3 4 5 

5 6 B - - 


Time TO 

Isolate Workaround 

Error Used 


Related to 
Previous 
Change 


Previous 
Form . 
Number 


Previous 

Form 

Date 


1 X 

i 
1 


Y 

N 

N 


00002 

780831 




Reason 

Comment 

Flag 


Description General 


Comment 

■-F lag 


Comment 

Flag 


Status 

Flag 


Y 


Y 


Y 


1 


Y 


Y 


N 


1 


Y 


Y 


N 


1 


See Appendix A, Section A. 8, for the file format. 

2, 2. 2. 3 Component Status Report (CSR) File 

The Component status Report File cont^J..si data on the amount 
of time spent by a programmer on, different activities and 
components (modules) in the development process. The time 
spent on components is divided into design, code, and test 
stages. One record on the CSR File represents one line on 
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the CSR form; a form may spread over several records. A 
record (line) contains the following: 

• Programmer 

e Form date 

e Component 

• Hours spent in each phase 

e Other activity (name) 

e Other activity (lours spent) 

The CSR form is filled out by the programmer once a week. 

Below are three sample records in the CSR File. The hours 
shown represent real numbers even though they are shown as 
integers. The correct real number value is obtained by 
dividing the given number by 10. Hyphens represent blanks. 


Form 

Number 

Sequence 

Number 

Project 

Programmer 

Form Date 

B03146 

• 

1 

36 

22137 

791012 

B03146 

2 

36 

22137 

791012 

B03146 

3 

36 

22137 

791012 


Design 

Create 

Design 

Read 

Design 

Review 

Code 

Component 

Hours 

Hours 

Hours 

Hours 

451 

100 

50 

0 

0 

50 

0 

0 

0 

0 

- 

- 

- 

- 

- 

Code 

Code 

Unit 

Integration 

Review 

Read 

Review 

Test 

Test 

Test 

Hours 

Hours 

Hours 

Hours 

Hours 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 
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Other 

Other 




Activity 

Activity 


Status 

Phase 

Name 

Hours 


_ Flag. 

Flag 

m 

m 


1 

D 

- 

- 


1 

D 

TRAVEL 

5 


1 

D 

See Appendix A, 

Section A. 9, for 

the 

file format. 


2. 2.2.4 Component Summary Form 

(CSP| 

File 



The Component Summary Form File contains a general descrip- 
tion of a component. This form is filled out by the pro- 
grammer twice: when a component is first defined, it is 

filled out with estimates of the effort and size of the com- 
ponent: when the component is completed, it is filled out 
with the actual values. There should be two forme for each 
component at the completion of a project. One record in the 
CSF File represents one form. Each record contains the fol- 
lowing information: 

• Programmer 

• Form date 

e Form stage 

• Component 

e Precision of specification 

• Complexity 

• Type of software 

e Type of statements 

e Number of statements 

• Relation to other software 

e Type of addition (if addition) 

e Number of components called, shared, and descendant 

e Languages used 

e Form of specification 

e Constraints (yes/no) 

• Number of design, code, and test runs 
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• Design, code, and test computer time used 
e Time/effort spent in design, code, and test 
e Design, code, and test end dates 

Below are three sample records on the CSF Pile. Hyphens 
represent blanks. 



Programmer 

Programmer 


Form 


Filling 

implementing 

Form 

Number 

Proiect 

Out Form 

component 

Date 

101878 

36 

2 

2 

800606 

101879 

36 

2 

2 

800617 

101880 

36 

3 

3 

800709 





Type of 

Form 

Precision of 


Software 

Stage Component Specification 

Complexity 

12 3 

N 

459 

3 

E 

3 - - 

N • 

456 

1 

E 

5 - - 

C 

462 

3 

M 

1 - - 

Percent of 

Percent of 

Percent of 

Lines 

Lines 

Assignment 

Control 

Other 

Without 

With 

Statements 

Statements 

Statements 

Comments 

Comments 

20 

50 

30 

50 

100 

0 

0 

100 

7 

25 

60 

10 

10 

55 

70 

Number of 

Indepei^dent 

Relation 

Type of 

Number of 

Machine 

of Other 

to Other 

Addition 

Components 

Bytes 

Software 

Software 

12 3 4 

Called 


N 

1 

1 4 - - 

2 

a* 

Y 

- 

.... 

0 

400 

Y 

- 

- - - - 

0 

Number 

Number of 

Number of 


Percent 

Calling 

Shrred 

Components 

Primary 

Primary 

This Comp 

Components 

Descending 

Language 

Language 

1 

0 

3 

1 

100 

0 

1 

0 

1 

100 

1 

0 

3 

1 

100 
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Percent Functional Procedural English 
Secondary Secondary Design Design Design 

Language Language 1 2 1 2 _1 2 ^ 


- 

. 

1 

4 

- 


Formal 

Other 

1 

Memory 

Exec Time 

m m 

Other 

Design 

Design 

Constraint 

Constraint 

Constraint 

1 2 

1 2 

Ves Ok 

Ves Ok 

yes Ok 


X X 


X - 

Design Code 


Design 

Runs 

Code 

Runs 

Test 

Runs 


Computer 

Time 


Computer 

Time 

0 

2 

4 


0 


10 

• 0 

2 

3 


0 


5 

0 

. • 

2 

6 


0 


10 

Test 

Computer 

Time 

Design 

Effort 

Code 

Effort 


Test 

Effort 

Estimated 
Design 
End Date 

100 

80 

70 


120 


800711 

20 

40 

30 


70 


800502 

120 

60 

60 


140 


800703 

Estimated 

Code 

End Date 

Estimated 

Test 

End Date 

Descr iption 
Comment 
Flag 

Components Called 
1 2 3 4 5 

800711 

800905 


Y 


94 

92 - - - 

800711 

801231 


Y 


- 

- - - - 

800703 

800711 


Y 


- 

« - - - 

Calling Components 
1 2 3 4 5 


Shared Components 
1 2 3 4 5 


83 


- 

- 

- 

- 

- 

451 

- 

- 

• 

- 

4 

*^1 

- 

- 

- 

- 

- 

> 

- 

- 

• 


2-17 


8070 



Components Affected 
by Reorganization 
1 2 3 4 5 


Form of Design 
Other Name 


DUMMY -OTHER-NAME-ABC 



useful 

Additional 

Constraint 

Items 

Comment 

Other Name 

Comment 

Flag 

DUMMY-NAME -ABCDEFGH I 

Y 

N 

- 

Y 

Y 

m 

N 

N 


See Appendix A, Section A.IO^ for the file format. 


Status 

,H£SL 

1 

1 

1 


2 . 2 . 2 . 5 General Project Summary (GPS) File 

The General Project Summary Pile contains a summary of re- 
sources, times, program sizes,- costs, and several other 
aspects of a project. The GPS form is filled out by the 
project manager or project leader at the beginning and end 
of the project and at the end of major phases. The follow- 
ing information is contained on the GPS File: 


e Project description 

e Resources used 

• Scheduling 

e Cost of project 

e Size of project 

e Computer access 

e Techniques employed 

e Formalisms used 

e Automated tools used 

e Type of project organization 

e Standards used 

e Milestones reached 

e Documentation issued 
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• Problems encountered 

• Quality assurance employed 

See Appendix A, Section A. 11, for the file format. 

2. 2. 2. 6 Resource Summary Form (RSF) File 

The Resource Summary Form File contains information on pro> 
grammar time, computer time and runs, and other service 
charges. The resources are recorded by the project manager 
for each week for up to 11 weeks on a single form. Each 
record in the file contains information from one line of the 
RSF File, either manpower, computer, or services data. A 
record contains the following information: 

• Resource type indicator (manpower, computer, or 

services) 

• Resource code 

e Form date 

e Percentage management 

e Beginning date of data 

e Hours each week (up to 11 weeks) 

e Number of comnuter runs each week (up to 11 weeks) 

Below are three sample RSF File records. The resource hours 
are integers representing real number values times 10. 
Hyphens indicate blanks. The number sign (#) indicates the 
week (1 through 11) . 


Form 

Number 

Sequence 

Number 

Project 

Resource 

Type 

Resource 

C00144 

1 

36 

M 

18024 

C00144 

2 

36 

M 

22137 

C00144 

3 

36 

C 

1 
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Form 

Date 

Percent 

Manaqement 

Beginning 
Date Of 
Data 



791214 


100 

791005 



791214 


10 

791005 



791214 


- 

791005 


Runs 
♦ 1 

Resource 

Hours 

#1 

Runs 

#2 

Resource 

Hours 

#2 

Runs 

Jtl- 

Resource 

Hours 

#3 

0 

100 

0 

100 

0 

100 

- 

- 

0 

240 

0 

400 

0 

240 

- 

- 

5 

10 

Runs 

#4 

Resource 

Hours 

#4 

Runs 

#5 

Resource 

Hours 

#5 

Runs 

#6 

Resource 

Hours 

#6 

0 

100 

0 

100 

0 

320 

0 

100 

0 

100 

0 

100 

0 

0 

4 

80 

0 

0 

Runs 

»7 

Resource 

Hours 

#7 

Runs 

#8 

Resource 

Hours 

#8 

Runs 

#9 

Resource 

Hours 

#9 

0 

100 

- 

- 

0 

100 

0 

385 

0 

240 

0 

400 

0 

0 

0 

0 

0 

0 

Runs 

#10 

Resource 

Hours 

#10 

Runs 

#11 

Resource 

Hours 

#11 

.'tat US 
Plaq 

Phase 

FJ-ag 

■) 

400 

m 

- 

1 

D 

- 

- 

- 

- 

1 

D 

0 

0 

0 

0 

1 

D 


See Appendix A, Section A. 12, for the file format. 

2. 2. 2. 7 Run Analysis Form (RAF) File 

The Run Analysis Form File contains information about com- 
puter runs made by a programmer on a project. The RAP, 
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filled out by the programmer # has data from up to nine sepa- 
rate runs. One record represents one line (run) on the 
RAF. The following information is contained on the RAF File: 

s Programmer 

e Run date 

e Computer model used 

e Interactive run indicator 

e Purpose of run (unit test, maintenance) 
e Number and type of conr.ponenti; 

e Whether or not first run 

e Whether or not run met objectives 

e Run results 

lelow are three sample records on the RAF Pile. Hyphens in- 
dicate blanks. 


Form 

Number 

Sequence 

Number Project 

Programmer 

Run 

Date 

J01946 

1 

42 

22137 

791025 

J01946 

2 

42 

22137 

791025 

J01946 

3 

42 

22137 

791026 


Interactive 


Run 



Run 


Purpose 

Number Of 

Computer 

Indicator 


12 3 4 

Components 

6 

X 


1 

1 

2 

6 

- 


7 - 

1 

3 

- 


7 - - - 

1 


Components 
1 2 3 4 5 


First Run 
Indicator 


Run Met 
Objectives 
Indicator 


280 4 - - - X Y 

10 - - - - 
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Run 

Result 
12 3 4 


Comment 

Indicator 


Status 

Flag 


1 4 - - N 1 

4 - - - N 1 

4 - - - N 1 

See Appendix A, Section A. 13, Cor the file format. 

2.2.3 AUXILIARY FILES 

This subsection describes the remaining six file types, 
which are identified as auxiliary files: 

1. Accounting Information (ACC) Pile 

2. Comment (CMT) File 

3. Component Information File (GIF) 

4. Growth History (HIS) File 

5. Source Analyzer Program (SAP) Output File 

6. Transaction Files 

2 . 2 . 3 . 1 Accounting Information (ACC) File 

The Accounting Information File contains accounting informa- 
tion for jobs run on the IBM S/360-95 and -75. Each record 
contains information relating to a specific 4-hour block of 
time (i.e., 1 day's activities on a computer are represented 
by six records) . A record contains the following informa- 
tion : 

• Date 

• Start time of 4-hour period 

• CPU and I/O time for the IBM S/360-95 and -75 

e Number of runs for the IBM S/360-95 and -75 

• Number of remote job entry (RJE) jobs 

• Number of card reader jobs 

This information is obtained from an accounting history tape 
on the IBM S/360, which is generated from an online account- 
ing system that monitors all activity on the particular ma- 
chine. 
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See Appendix A, Section A. 14, tot the file format. 


2. 2.3.2 C omment (CMT) File 


The Comment Pile contains all commenua from the Change Re- 
port Form, the Component Summary Form, and the Run Analysis 
Form for a qiven project. (The component status report and 
resource summary forms do not have comment fields.) Each 
record on the CMT File contains a comment and the number of 
the originating form. This file is automatically updated by 
DBAM whenever one of the form types with comments is proc- 
essed. This information is stored separately, since it was 
felt that most users of the form data files would generally 
not want the comment information. Therefore, the form data 
files were made smaller by deleting this text information. 


Below are three sample records on the CMT File: 
Form Sequence 


Number 

101878 

101879 

101880 


Number 

I 

I 

1 


Comment 

D 

D 

U 


Record 

Number 

1 

1 

I 


Project 

36 

36 

36 


Continuation 


Indicator 

Text 


Status 

Flag 


N PILL PREREAD ARRAYS 1 
N DRIVER FOR READING TELEMETRY RECORDS 1 
N CHECKS BUFFER SIZE 1 


See Appendix A, Section A. 15, for the file format. 
2. 2. 3. 3 Component Information File (CIF) 


The Component Information Pile was developed to characterize 
each component. This file contains several source code sta- 
tistics for each component. Some of the items are general 
library information, such as how many changes were made to a 
compv'nent. The rest are statistics extracted from the 
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FORTRAN source code of the component by SAP. Each GIF rec- 
ord contains the following information: 

• Component name and code 

• PANVALBT level number (number of source changes) 

• i^^odule and subsystem function 

• Whether component is new» old, or modified 

• Number of executable statements 

• Number of lines with comments 

• Number of comment lines 

• Number of unique operators 

• Number of unique operands 

• Total number cf operators 

• Total number of operands 

• Number of input and output variables from module 

• Number of decisions 

• Number of FUNCTION references 

• Number of I/O statements 

• Number of assignment statements 

• Number of CALL statements 

• Number of FORMAT statements 

Note that operands and operators are software measures de- 
scribed by Halstead in Reference 4. 

There is a unique correspondence between the component name 
and component code listed above that serves as a dictionary 
for all component codes used in other data base files for a 
particular project. 


Below are 

three sample 

records on the 

GIF. Hyphens 

indicate 

blanks. 





Project 

Component 

Name 

Component 

Code 

PAN VALET 
Level 
Number 

Module 

Function 

19 

ACBIAS 

275 

4 

- 

19 

ACBIASM 

3 50 

- 

- 

19 

ACBIAS UN 

3 51 

- 

- 



Subsystem 

Function 

Origin 

Executable 

Statements 

Source 

Lines 

Comments 

- 

- 

90 

254 

102 

- 

1 

31 

104 

44 

- 

1 

17 

89 

43 

Operators 

Operands 

Total 

Operators 

Total 

Operands 

Input and 
Output 
Variables 

24 

64 

421 

315 

29 

9 

25 

158 

155 

9 

9 

19 

70 

67 

10 

Decisions 

FUNCTION 

References 

I/O 

Statements 

Assignment 

Statements 

CALL 

Statements 

21 

29 

1 

50 

18 

2 

0 

1 

27 

0 

2 

0 

• 1 

13 

0 


FORMAT 

Statements 

Status 

Flag 



2 


1 



2 


1 



2 


1 


See Appendix A, Section 

A. 16, for the 

file format. 


2. 2.3.4 Growth History 

(HIS) File 



The Growth 

History File 

contains information about 

the 


changing number of modules and lines of code for each proj- 
ect. Each record contains a date and the total number of 
source code lines, modules, and changes up to that date. 
This information comes from weekly listings of the PANVALET 
library directory for projects using the IBM computers and 
from weekly file directory listings for projects using the 
DEC computers. 
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Below are 

three sample records 

from the 

HIS File. 


Project 

Date 

Source 
Lines 
to Date 

Modules 
to Date 

Changes 
to Date 

statu. 

10 

770923 

12414 

143 

12 

1 

10 

770930 

12414 

143 

12 

1 

10 

771007 

15973 

172 

56 

1 


See Appendix Pi, Section A. 17, for the file format. 

2. 2. 3. 5 SAP Output File 

The SAP Output File is a single intermediate sequential file 
containing several source code statistics produced by SAP. 
Each record in this file contains information on individual 
components, such as the number of executable statements and 


the number 

of assignment statements 

. The record 

format is 

similar to 

that of the 

CIF but not 

Identical. Some rear- 

rangement 

is made before DBAM. moves 

the data into 

the appro- 

priate CIF 

e 


• 

• 

Below are 

three sample 

records from 

the SAP Output File. 

Project 

Module 

Parameters 

Comment 

Executable 

Name 

Name 

Passed In 

Lines 

Statements 

PROJ2 

ACDUMFLl 

28 

105 

93 

PROJ2 

TPTPCHEK 

3 

63 

12 

PROJ5 

DAINRT 

6 

32 

1 

I/O 

Source 



Total 

Statements 

Lines 

Operators 

Operands 

Operators 

1 

252 

12 

105 

316 

1 

82 

7 

8 

27 

0 

39 

0 

0 

0 
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Total 

Operands 

Number Of 
IF and .IF 
Statements 

Decisions 

Input and 
Output Var. 
to Module 

COMMON 

Variables 

280 

1 

4 

57 

6 

12 

5 

6 

3 

0 

0 

0 

0 

6 

0 

DO and 

DOWHILB 

FUNCTION 

Structured 

Parameters 

Assignment 

Statements 

References 

Statements 

Passed Out 

Statements 

3 

0 

0 

73 

64 

0 

0 

8 

5 

0 

0 

0 

0 

0 

0 


CALL 

FORMAT 

Statements 

Statements 

22 

2 

5 

1 

% 

0 

0 


See Appendix A, Section A.18r for the file format. 

2. 2.3.6 Transaction Files 

Transaction Files are sequential backup disk files that con- 
tain a record of all additions, deletions, and changes made 
to the data base since the last DBAM backup. (A DI»AM tape 
backup run resets the number of transaction records to zero.) 
There are seven transaction files in the data base: one for 

each form type (CRF, CSF, CSR, RAF, and RSF) , one for the 
CIFs, and one for the HIS Files. DBAM automatically adds to 
the Transaction Files whenever data in the data base are 
added, changed, or deleted. 

See Appendix A, Section A. 19, for the file format. 

2.3 GENERAL NOTES ON THE DATA BASE DATA 

All data on the data base are stored in character format. 

All fields displayed as numbers are right justified and 
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blank filled except for datea» which are zero filled with a 
format of YYMNDC. In many cases, an all-blank integer field 
(as opposed to a zero) indicates missing data. 

Component codes are associated with component names on the 
CIFs, whereas all other coded fields are defined on the En- 
coding Dictionary. 

All forms processed are given a unique six-character string 
(a letter followed by five digits) --for example, B00138.^ 

The letter represents the form type as follows: 


A 

or 

J 

Run Analysis 

RAF 

B 



Component Status 

CSR 

C 



Resource Summary 

RSF 

D 

or 

K 

Change Report 

CRP 

E 

or 

I 

Component Summary 

CSF 


A phase flag (R, D, or M) indicates whether the form came 
from the requirements, development, or maintenance teams. 
(Development in this case refers to the time between the 
design start date and the cleanup end date as defined on the 
Phase Dates Pile.) 

All but four file types have a status flag. (The Encoding 
Dictionary, the File Name and Status File, the Subjective 
Evaluations Directory File, and the SAP Output File do not 
have status flags.) New records are entered with a status of 
1 (for "unchecked**). After hand validation, the status will 
be reset to 2. After data are verified by application, the 
status will be reset to 3. 


^The format of the RAP, CRP, and CSR forms has evolved. 
Each revision of a form was assigned a new prefix to the 
form number. Thus, in some cases a file may contain form 
records with form numbers prefixed by one of two possible 
letters. 
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SECTION 3 ■ DATA BASE USER'S GUIDE 


This section contains information on data base access and 
use. It is assumed that the user understands the basic 
operation and capabilities of the DEC PDP-11/70 (Refer- 
ences 5 and 6) . This section also describes the capabili- 
ties of DBAM (Reference 2), a general indexed file access 
program (DATATRIEVE) (Reference 7 ) , and several other basic 
profile reporting programs. The support software that is 
described includes the following: 

1. DBAM--Data Base Maintenance Software# used to ac- 
cess and validate data base data 

2. SEL data base header files listing procedures-- 
DATATRIEVE command procedures to list the contents 
of the SEL data base header files 

' 3. NF--Form-counting report program that counts the 

number of forms by programmer for a given project 

4. RPSTSCTR--Record-counting report program that 
counts the number of records on each data base file 

5. WK--Hour- and form-counting report program that 
counts forms and programmer hours by programmer by 
week for a given project for any form type 

6. PF--Basic profile report program that sums re- 
sponses from files of any form type 

7. RU--Resource utilization report program that sum- 
marizes manpower and computer resources 

8. CS--Detailed component status report program that 
reports CSR File data by programmer by project 

9. REP4, REP5--CIF reporting programs that list compo- 
nents# their software type# and Halstead measures 
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All these programs reside on DBl: [204,5] (except DATATRIEVB, 
which is already installed). Helpful user information also 
exists on the .HLP files on DBl: [204,5]. 

3.1 DATA BASE MAINTENANCE SOFTWARE 

The DBAM system has five basic functions: 

1. CREATE--Create new files for given project. 

2. ARCHIVE--Back up all data base files on tape. 

3. RESTORE- -Restore all or specific files of the data 
base from the backup tape. 

4. COMPRESS- -Compress data base files to reduce space 
used and increase access efficiency. 

5. UPDATE--Add, change, or delete data base records. 
All new data are validated to prevent the entry of 
incorrect data. UPDATE is the primary function 
used in the general data entry process. 

To run this program, the user must log on under [204,3] (no 
password) and enter the following (the indirect command 
file) : 

@SELDBS 

For complete information on how to run DBAM, see file 
DBl; [204,5 ]SELDBS. HLP or Reference 2. 

3.2 SEL DATA BASE HEADER FILES LISTING PROCEDURES 

The following five DATATRXEVE command procedures are used to 
list the contents of the five SEL data base header files: 

1. DBRPTDIR--Lists the contents of the Subjective 

Evaluations Directory file and produces a formatted 
report in SEFDIR.RPT under the user's user identi- 
fication code (UIC) 
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2. DBRPTENC— List! th« contents ot the Encoding Dic- 
tionary and products a formatted report in ENC.RPT 
under the user*s UIC 

3. DBRPTEST--Lists the contents of the Estimated Sta- 
tistics File and produces two formatted reports in 
ESTl.RPT and EST2.RPT under the user's UIC 

4. DBRPTHDR--Lists the contents of the Phase Dates 
Pile and produces a formatted report in hdr.RPT 
under the user's UIC 

5. DBRPTSTS--Lists the contents of the File Name and 
Status File and produces a formatted report in 
STAT.RPT under the user's UIC 

DATATRIEVE is a DEC-suppliedr file-access program allowing 
formatted listings to be made of the record contents of any 
Record Management System (RMS) indexed file. DATATRIEVE 
should be used to verify exactly whal data exist in the data 
base. To execute these procedures, the user enters DTR. A 
prompt of "DTR>" is displayed to indicate that DATATRIEVE 
is running. The user nan then enter the indirect file name 
for the desired listings: @ [204,4] DBRPTDIR. DTR, @[204,4] 

DBRPTENC.DTR, @ [204,4] DBRPTEST. DTR, @ [ 204,4] DBRPTHDR. DTR, or 
@ [204,4] DBRPTSTS. DTR. For more information on how to use 
DATATRIEVE, see Reference 7. 

3.3 FORM COUNTER (NF) 

This form-counting program produces a one-page report of the 
number of each type of form on the data base for each pro- 
grammer for a particular project. Indirect files are al- 
lowed in response to the prompt for a project name. 

3.4 RECORD COUNTER (RPSTSCTR) 

This record-counting program produces a single-page report 
of the number of all records in all file types for all proj- 
ects. Note that for some file types, the number cf' records 
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•quAls the number of forme and that for other file types 
they are not equal. 

3.5 HOUR AND FORM COUNTER BY WEEK (WK) 

This program produces a one- to two-page report of the num- 
ber of forms or the number of hours or runs by programmer by 
week for a specific project. Indirect files are allowed. 

3.6 GENERALIZED RESPONSE ACCUMULATOR (PF) 

This is a basic profile program that currently reports on 
four file typest the CIF» the CRF Filer the CSF File* and 
the RAF File. This program reports the counts of the re- 
sponses of each field broken down by another field count. 
Indirect files are allowed. 

3.7 RESOURCE UTILIZATION REPORT (RU) 

The resource utilization report program produces a three- 
page report of manpower and computer resource data of a 
given project. There are two sections to the report. The 
first is a summary of programmer, manager, and services 
hours brokOii down by the five middle phases on the Phase 
Dates File. The second section shows run, change, and line 
counts. 

This program obtains the resource data first from the RSF 
File and then from the CSR File. 

3.8 DETAILED COMPONENT STATUS REPORT (CS) 

This program produces a report of the data on a specific 
project's CSR File. The report prints separate sections for 
each programmer on the project. Each section has two parts: 
the activity section, which is a summary of OTHER hours, and 
the component section, which lists the hours spent on each 
component. 
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3.9 C OMPONENT INFORMATION FILE REPORTS (RBP4, REPS) 

Two similar rsport programs product detailed reports of the 
CIP. The firstf REPS, produces a list of components and 
their associated Halstead parameters computed from the basic 
data on each CIF record. (For more information on Halstead's 
measures, see Reference 4.) The second report, RBP4, pro- 
duces a similar list of components and associated data by 
type of software and sorted by number of executable state- 
ments. 

The type of software categories used in REP4 are listed be- 
low: 


Code 

Type 

A 

I/O (input/output) 

B 

Control/driver 

BA 

Control/driver with I/O 

C 

ContTol/computational 

CA 

Control/computational with I/O 

D 

Algorithmic/data transfer 

DA 

Algorithmic/data transfer with I/O 

E 

Block data 

POTENTIAL 

PROBLEMS 


This subsection contains some notes on situations that may 
prevent further processing. 

1. If an unfamiliar abnormal end (ABEND) of execution 
occurs while running a program, the complete error message 
should be recorded and brought to the attention of program- 
ming personnel or the data base administrator. An ABEND may 
lock files, which means that those files are inaccessible 
and the program may not be run again until the files are 
unlocked. 
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2. To unlock a locked file, the usee must either log 
on with the UIC of the owner of the file or use the main 
console (privileged UIC) and enter "PIP f ile>ext/UN". 

3. If the VTIOO keyboard locks for any reason (nothing 
can be entered) , the SET-UP key should be pressed twice to 
unlock it. 

4. If a user program continues to run beyond its de- 
sired use, it can be terminated or stopped by entering "ABO 
TTn" (ABORT), where n is the terminal number. If it is an 
installed program such as DTR or FOR, it can be terminated 
by entering "ABO nam", where nam is the three-letter name of 
the program. If new output continues to be displayed on the 
screen, CONTROL C should be entered before trying to ter- 
minate. 
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APPENDIX A - DATA BASE FILE FORMATS 


This appendix describes, in detail, field definitions for 
all files in the data base. 

Record Name or 


Section 

Paqe 

Lenqth 

Extension 

File Description 

A.l 

A- 2 

60 

ENCODE. HDR 

Encoding Dictionary 

A. 2 

A-3 

120 

EST.HDR 

Estimated Statistics 

A. 3 

A-5 

52 

STAT.HDR 

File Name and Status 

A. 4 

A- 6 

112 

HEADER. HDR 

Phase Dates 

A. 5 

A-8 

Variable 

SEF.HDR 

Subjective Evaluations 

A. 6 

A-48 

100 

DIR. HDR 

Subjective Eva.luacions 
Directory 

A. 7 

A-49 

72 

ATM 

Attitude Maintenance 
Change Report 

A. 8 

A-51 

101 

CRF 

Change Report Form 

A. 9 

A-55 

79 

CSR 

Component Status Repof^t 

A. 10 

A-56 

250 

CSF 

Comported t Summary Form 

A. 11 

A-61 

0 

GPS 

General Project Summary 

A. 12 

A-62 

115 

RSF 

Resource Summary Form 

A. 13 

A-63 

53 

RAF 

Run Analysis Form 

A. 14 

A-65 

67 

ACC 

Accounting Information 

A. 15 

A-67 

104 

CMT 

Comment 

A. 16 

A-68 

80 

CIF 

Component Information 

A. 17 

A-70 

29 

HIS 

Growth History 

A. 18 

A-71 

78 

ALL. SAP 

Source Analyzer Pro- 
gram output (for all 
projects) 

A. 19 

A-72 

- 

— 

Transaction (different 
record length for each 


file) 

The seven Transaction Files are located on DBO: (204,1). 
Component codes are defined in the GIF. 
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A. 1 ENCODING DICTIONARY (ENC) FILE 


Item 

Location 

Format 

Descr iotion 

1 

1-3 

13 

Code type 

Numeric code identi- 
fying the category 

2 

4-8 

AS 

code 

Alphanumeric code 
identifying a par- 
ticular value 

3 

9-16 

A8 

Abbreviation 
(e.g., JCLERROR) 

4 

17-60 

44A1 

Verbal description of 
code 

Primary 

key: Code 

type and code 

(bytes 1 through 8) 


Secondary key: Code type and abbreviation (bytes 1 through 3 

and 9 through 16, split key) 
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CM 

• 

< 

ESTIMATED 

STATISTICS (EST) 

FILE 

Item 

Location 

Format 

Description 

I 

1-8 

8Al 

Project name 
(e.g., MAGBIAS) 

2 

9-10 

12 

Project code from ENCODE. HDR 

3 

11-14 

14 

Number of components 

4 

15-18 

14 

Total number of modules 

5 

19-22 

14 

Number of new modules 

6 

23-26 

14 

Number of modified modules 

7 

27-32 

16 

Number of computer runs 

8 

33-38 

16 

Number of source code changes 

9 

39-44 

16 

Number of pages of documen- 
tation 

10 

45-50 

16 

Total number of lines of code 

11 

51-56 

16 

Number of new lines of code 

12 

57-62 

16 

Number of modified lines of 
code 

13 

63-68 

16 

Total number of executable 
statements 

14 

69-74 

16 

Number of new executable 
statements 

15 

75-80 

16 

Number of modified execut- 
able statements 

16 

81-86 

P6.1 

Programmer work hours (in 
tenths) 

17 

87-92 

P6.1 

Management work hours (in 
tenths) 

18 

93-98 

P6.1 

Other (services) work hours 
(in tenths) 

19 

99-104 

F6.1 

IBM S/360-95 computer hours 
(in tenths) 

20 

105-110 

F6.1 

IBM S/360-75 computer hours 
(in tenths) 

21 

111-116 

F6.1 

Other computer hours (in 


tenths) 
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Loi'at Ion 


I tom 


Foiinat Peace Ipt ion 


117 


2^ 118 


24 119 


II Status £laq: 

■ I, unchecked 

■ 2 , hand checked 

• 3, verified by application 

A1 Active fia* 3 i; 

" Y, active 
» N, Inwictive 
» blank, no reaponao 

II Project category: 

■ 1, attitude oriented 
» 2, orbit oriented 

« 3, scientific oriented 

■ 4, data base oriented 

■ 5, tool 

- 6, real time 

■ 7, other 

■ blank, no response 

Al Spare 


Primary key: Project code (by tea 9 throuvjh 10) 

Secondary key; Project name (bytes I through 8) 
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A. 3 FILK 

NAME 

AND STATUS 

(STS) FILE 

Item Location 

Format 

Description 

1 

1-2 

12 

Project code from ENCODE. HDK 

2 

3-4 

12 

File code from ENCODE. HDR 

3 

5-29 

25A1 

File name (fully qualified) 
(e.q., DBl; [204.1 ISMM.RSF) 

4 

30-35 

Ib 

Creation date of file 
(YYMMDD) 

5 

36-41 

16 

Last backup date of file 
(YYMMDD) 

6 

42-47 

16 

Last update date of file 
(YYMMDD) 

7 

48-52 

15 

Number of records in file 

Pclmatry key: 

Project code and file code (bytes 1 
through 4) 

Secondary 

key : 

Project c( 

ude (bytes 1 and 2) 

Tertiary 

key ; 

File code 

(bytes 3 and 4) 

Quaternary key: 

File name 

(bytes 5 through 29) 
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A. 4 

PHASE DATES FILE 

(HDR) 


Item 

Location 

Format 

Description 

1 

1-8 

8A1 

Project name 
(e.g., MAGBIAS) 

2 

9-10 

12 

Project code from ENCODE. HDR 

3 

11-12 

12 

Development computer from 
ENCODE. HDR: 

* 1, IBM S/360 

• 2 , DEC PDP-11/70 

■ blank, no response 

4 

13-14 

12 

Target computer from 
ENCODE. HDR: 

« 1, IBM S/360 
- 2 , DEC PDP-11/70 
■ blank, no response 

5 

15 

11 

Extent of alien computer use 

6 



PHASE DATES 

7 

16-21 

16 

Requirements start 
(YYMMDD) • 

8 

22-27 

16 

Requirements end (YYMMDD) 

9 

28-33 

16 

Design start (YYMMDD) 

10 

34-39 

16 

Design end (YYMMDD) 

11 

40-45 

16 

Code and test start 
(YYMMDD) 

12 

46-51 

16 

Code and test end (YYMMDD) 

13 

52-57 

16 

System test start (YYMMDD) 

14 

58-63 

16 

System test end (YYMMDD) 

15 

64-69 

16 

Acceptance test start 
(YYMMDD) 

16 

70-75 

16 

Acceptance test end 
(YYMMDD) 

17 

76-81 

16 

Cleanup start (YYMMDD) 

18 

82-87 

16 

Cleanup end (YYMMDD) 

19 

88-93 

16 

Maintenance start (YYMMDD) 

20 

94-99 

16 

Maintenance end (YYMMDD) 

21 

100-111 

A12 

Spares 
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Item 


Location 


Format 


Description 


22 112 


Primary key: 
Secondary key: 


II Status flag: 

• 1, unchecked 

- 2 , hand checked 

■ 3, verified by application 

Project code (bytes 9 and 10) 

Project name (bytes 1 through 8) 
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A. 5 SUBJECTIVE EVALUATIONS FILE (SEF) 

Each proje-rt has seven records of varying length as 
described below. 

A. 5.1 SEP RECORD 1 


Item 

Location 

Format 

1 

1-2 

12 

2 

3 

11 

3 

4 

11 


4 

5 

11 

5 

6-7 

F2.1 

6 

8-9 

P2.1 

7 

10-11 

F2.1 

8 

12-13 

P2.1 

9 

14-15 

P2.1 

10 

16-17 

F2.1 

11 

18-19 

F2.1 

12 

20-21 

F2.1 

13 

22-23 

F2.1 

14 

24-25 

F2. 1 

15 

26-27 

F2.1 

16 

28-29 

F2. 1 

17 

30-33 

F2.1 

18 

32-33 

F2. 1 


Description 

Project code from ENCODE. HDR 

Record sequence number 

Status flag for the 
Practices and Techniques 
(MT) measure: 

■ 1, unchecked 

» 2 , hand checked 

« 3, verified by application 

Evaluation code for the MT 
measure 

ORGANIZATION 

Chief programmer 

Not defined 

DESIGN 

Walkthroughs 
Formal reviews 
Formalisms 
Tree charts 

Program Design Language 
(PDL) 

Hierarchical Input Proc- 
essing Output (HIPO) 

Top-down 

Iterative enhancement 
N-squared charts 
Not defined 
Not defined 
Not defined 
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Item 

Location 

Format 

19 

34-35 

P2.1 

20 

36-37 

P2.1 

21 

38-39 

F2.1 

22 

40-41 

P2.1 

23 

42-43 

F2.1 

24 

44-45 

P2.1 

25 

46-47 

F2.1 

26 

48-49 

F2.1 

27 

50-51 

F2.1 

28 

52-53 

F2.1 

29 

54- 55 

P2.1 

30 

56-57 

P2.1 

31 

58-39 

P2.1 

32 

60-61 

F2.1 

33 

62-63 

F2.1 

34 

64-65 

F2.1 

35 

66-68 

P3.1 

36 

69-71 

P3.1 

37 

72-74 

F3.1 

38 

75-78 

P4.1 

39 

79 

11 


40 

80 

11 

41 

81-82 

P2.1 

42 

83-84 

P2.1 

43 

85-86 

F2.1 


Description 

CODE 

Stubs 

Top-down 

Structured 

Walkthroughs 

Reading 

Configuration control 
Not defined 
Not defined 
Not defined 
TEST 

rormalisni 

Pollowthrough 

Batch 

IV & V presence 
IV s V use 
Not defined 
Not defined 
SUMS 

Items 7 through 14 

Items 19 through 24 

Items 28 through 32 

Items 35 through 37 and 

item 5 

Status flag for the Tools 
(TS) measure: 

« 1, unchecked 

* 2 , hand checked 

« 3, verified by application 

Evaluation code for the TS 
measure 

Formal training in 
methodology 

Informal training 

Methodology reinforcement 
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Item Location Format 


Description 


44 

87-88 

P2.1 

45 

89-90 

F2.1 

46 

91-92 

F2.1 

47 

93-94 

F2.1 

48 

95-96 

P2.1 

49 

97-98 

P2.1 

50 

99-100 

F2.1 

51 

101-102 

P2.1 

52 

103-104 

P2.1 

53 

105-106 

P2.1 

54 

107-108 

P2.1 

55 

109-110 

F2.1 

56 

111-113 

F3.1 

57 . 

114 

11 


58 

115 

11 

59 

116-117 

P2.1 

60 

118-119 

P2.1 

61 

120-121 

P2.1 

62 

122-123 

P2.1 

63 

124-125 

F2.1 

64 

126-127 

P2.1 

65 

128-129 

P2.1 

66 

130-131 

F2.1 

67 

132-133 

F2.1 

68 

134-135 

F2.1 


Requirements language 
(MEDL-R) 

Design language (PDL) 

Precompiler (SPORT) 

Software aids (e.g.# XREF» 
MAP, LIST) 

Librarian 

Data generators 

Terminals (TSO) 

Remote Job Processing (RJP) 

Configuration Analysis Tool 
(CAT) 

Not defined 
Not defined 
Not defined 

Sum items 41 through 52 

• 

Status flag for the Docu- 
mentation (DC) measure: 

’■ 1 , unchecked 

« 2 , hand checked 

■ 3, verified by application 

Evaluation cede for the DC 
measure 

SEL forms 

Design document 

Design decisions 

Semiformal quality assurance 

Activity notebooks 

Unit development folders 

Test plans 

User's guide/system 
description 

Formal treatment of user's 
guide/system description 

Weekly/monthly progress 
reports 
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Item 

Location 

Format 

Description 

69 

136-137 

F2.1 

Not defined 

70 

138-139 

F2.1 

Not defined 

71 

140-141 

F2.1 

Not defined 

72 

142-143 

F2.1 

Not defined 

73 

144-145 

F2.1 

Not defined 




SUMS 

74 

146-148 

F3.1 

Items 59 through 68 

75 

149-152 

F4.1 

Item 38, item 56*500/ 
600, and item 74 

76 

153-162 

AlO 

Spares 


Primary kay: Project code and record lequence number 

(bytes 1 through 3) 
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A. 5.2 SEF RECORD 2 


Item 

Location 

Format 

1 

1-2 

12 

2 

3 

11 

3 

4 

11 


4 

5 

11 

5 

6-7 

F2.1 

6 

8-9 

F2.1 

7 

10-11 

F2.1 

8 

12-13 

P2.1 

9 

14-15 

F2.1 

10 

16-17 

F2.1 

11 

18-19 

F2.1 

12 

20-21 

P2.1 

13 

22-23 

P2.1 

14 

24-25 

F2.1 

15 

26-27 

P2.1 

16 

28-29 

P2.1 

17 

30-31 

P2.1 

18 

32-33 

P2.1 

19 

34-35 

P2.1 

20 

36-38 

P3.1 

21 

39-41 

P3.1 

22 

42-44 

P3.1 

23 

45-47 

P3.1 


DtlCClptlon 

Project code from ENCODE. HDR 

Record sequence number 

Statue flag for the 
Experience with Application 
(AP) measure; 

- 1, unchecked 

■ 2 , hand checked 

■ 3 , verified by application 

Evaluation code for the AP 

measure 

Expert 1 
Expert 2 
Expert 3 
Expert 4 
Expert 5 
Project manager 
Project leader 
Programmers 
Analysts 

Participation in 
requirements definition 

Participation in design 

Team interactions before 
project 

Not defined 

Not defined 

Not defined 

SUMS 

Items 5 through 9 
Items 10 through 12 
Items 14 through 16 
Items 5 through 16 


A-12 


8070 



Item 

Location 

Format 

24 

48 

11 


25 

49 

11 

26 

50-51 

F2.1 

27 

52-53 

F2.1 

28 

54-55 

F2.1 

29 

56-57 

F2.1 

30 

58-59 

F2.1 

31 

60-61 

F2.1 

32 

62-63 

F2.1 

33 

64-65 

F2.1 

34 . 

66-67 

F2.1 

35 

68-69 

P2.1 

36 

70-71 

F2.1 

37 

• 

72-73 

F2.1 

38 

74-75 

F2.1 

39 

76-77 

F2.1 

40 

78-79 

F2.1 

41 

80-81 

F2.1 

42 

82-83 

F2.1 

43 

84-85 

F2.1 

44 

86-87 

F2.1 

45 

88-89 

F2.1 

46 

90-91 

F2.1 

47 

92-93 

F2.1 


Dticription 

Status flag for tha 
Ef factivansss of Nanagamant 
(MG) maasurai 
■ 1, unchackad 
« 2, hand chackad 
• 3, varifiad by application 

Evaluation coda for tha MG 
measure 

PRELIMINARy DESIGN 
Projact managar 
Projact laadar 
Analysis managar 
Analysis laadar 
Development managar 
Development leader 
DETAILED DESIGN 
Project managar 
Project leader 
Malysis manager 
Analysis leader 
Development manager 
Development leader 
IMPLEMENTATION 
Project manager 
Project leader 
Analysis manager 
Analysis leader 
Development manager 
Development leader 
SYSTEM TESTING 
Project manager 
Project leader 
Analysis manager 
Analysis leader 
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Item 

Location 

Format 

48 

94-95 

F2.1 

49 

96-97 

F2.1 

50 

98-99 

F2.1 

51 

100-101 

F2.1 

52 

102-103 

F2.1 

53 

104-105 

B’2.1 

54 

106-107 

F2.1 

55 

108-109 

P2.1 

56 

110-111 

F2.1 

57 

112-113 

F2.1 

58 

114-115 

F2.1 

59 

116-117 

F2.1 

60 

118-119 

F2.1 

61 

120-122 

F3.1 

67 

123-125 

F3.1 

63 

126-128 

P3.1 

64 

129-131 

F3.1 

65 

132-134 

P3.1 

66 

135-137 

F3.1 

67 

138-140 

F3.1 

68 

141-143 

F3.1 

69 

144-146 

P3.1 

70 

147-149 

P3.1 

71 

150-152 

P3.1 

72 

153-155 

P3.1 

73 

156-159 

F4.1 

74 

160 

11 


Description 

Development manager 
Development leader 
ACCEPTANCE TESTING 
Project manager 
Project leader 
Analysis manager 
Analysis leader 
Development manager 
Development leader 
STABILITY 

Project manager 
Project leader 
Analysis manager 
Analysis leader 
Other changes 
SUMS 

Items 26 through 31 

Items 32 through 37 

Items 38 through 43 

Items 44 through 49 

Items 50 through 55 

Items 56 through 60 

Items 26 , 32 , 38 , 44 , 50 

Items 27 , 33 , 39 , 45 , 51 

Items 28, 34, 40, 46, 52 

Items 29, 35, 41, 47, 53 

Items 30, 36, 42, 48, 54 

Items 31, 37, 43, 49, 55 

Items 26 through 60 

Status flag for the 
Performance of Team (PP) 
measure: 

* 1, unchecked 

* 2, hand checked 

» 3, verified by application 


A-14 


8070 



tern 

Location 

Format 

Descr iption 

75 

161 

11 

Evaluation code for the PF 
measure 

76 

162-164 

F3. 2 

Design - programmers 
DESIGN - TECHNICAL STAFF 

77 

165-167 

F3.2 

Programmers and project 
managers 

78 

168-170 

F3. 2 

Programmers, project man- 
agers, and analysis man- 
agers 

79 

171-173 

F3.2 

Programmers and develop- 
ment managers 




DESIGN - DEVELOPMENT MAN- 
AGEMENT 

80 

174-176 

F3. 2 

Project 

81 

177-179 

F3. 2 

Project and analysis 

82 

180-182 

F3. 2 

Devc* lopment 




DESIGN - INTERFACE MANAGE- 
MENT 

83 

183-185 

F3.2 

Analysis 

84 

186-188 

F3. 2 

Development 

85 

189-191 

F3. 2 

Design - not defined 

86 

192-194 

?3. 2 

Implementation - programmers 




IMPLEMENTATION - TECHNICAL 
STAFF 

87 

195-197 

F3. 2 

Programmers and project 
managers 

88 

198-200 

F3. 2 

Programmers, project man- 
agers and analysis man- 
agers 

89 

201-203 

P3. 2 

Programmers and develop- 
ment managers 




IMPLEMENTATION - DEVELOP- 
MENT MANAGEMENT 

90 

204-206 

F3. 2 

Project 

91 

207-209 

F3. 2 

Project and analysis 

92 

210-212 

F3. 2 

Deve] jpment 


A-15 


8070 


Item 

Location 

Format 

Description 

93 

213-215 

P3.2 

IMPLEMENTATION - INTERFACE 
MANAGEMENT 

Analysis 

94 

216-218 

P3.2 

Development 

95 

219-221 

P3.2 

Implementation - not defined 

96 

222-224 

P3.2 

Test - programmers 

97 

225-227 

P3.2 

TEST - TECHNICAL STAFF 
Programmers and project 

98 

228-230 

P3.2 

managers 

Programmers, project man- 

99 

2 : 1-233 

P3.2 

agers, and analysis man- 
agers 

Programmers and develop- 


ment managers 

TEST - DEVELOPMENT MANAGE- 
MENT 


100 

234-236 

^•3.2 

Project 

101 

• -237-239 

P3.2 

Project and analysis 

102 

240-242 

P3.2 

Development 




TEST - INTERFACE MANAGEMENT 

103 

243-245 

F3.2 

Analysis 

104 

246-248 

P3.2 

Development 

105 

249-251 

F3.2 

Test - not defined 

106 

252-254 

F3.2 

Overall - programmers 
OVERALL - TECHNICAL STAFF 

107 

255-257 

P3.2 

Programmers and project 
managers 

108 

258-260 

P3.2 

Programmers, project man- 
agers, and analysis man- 
agers 

109 

261-263 

P3.2 

Programmers and develop- 
ment managers 




OVERALL - DEVELOPMENT MAN- 
AGEMENT 

110 

264-266 

P3.2 

Project 

111 

267-269 

P3.2 

Project and analysis 
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Item 

Location 

Format 

Description 

112 

270-272 

P3.2 

Development 

OVERALL - INTERFACE MANAGE- 
MENT 

113 

273-275 

P3.2 

Analysis 

114 

276-278 

P3.2 

Development 

115 

279-281 

P3.2 

Overall - not defined 
SUMS 

116 

282-285 

P4.1 

Items 23r 61, 62, and 
item 76*600/300 

117 

286-289 

F4.1 

Items 23, 61, 62, and 
item 77*600/309 

118 

290-293 

F4.1 

Items 23, 61, 62, and 
item 78*600/314 

119 

294-297 

F4.1 

Item 23, item 63*2, and 
item 86*600/300 

120 

298-301 

F4.1 

Item 23, item 63*2, and 
item 87*600/309 

121 

302-305 

P4.1 

Item 23, item 63*2, and 
item 88*600/314 

122 

306-309 

F4.1 

Items 23, 64, 65, and 
item 96*600/300 

123 

310-313 

P4.1 

Items 23, 64, 65, and 
item 97*600/309 

124 

314-317 

F4.1 

Items 23, 64, 65, and 
item 98*600/314 

125 

318-321 

P4.1 

Item 23, item 73*600/ 

1750, and item 106*600/300 

126 

322-325 

F4.1 

Item 23, item 73*600/ 

1750, and item 107*600/309 

127 

326-329 

F4.1 

Item 23, item 73*600/ 

1750, and item 108*600/314 

128 

330-339 

AlO 

Spares 

Primary 

key: Project 

(bytes 

code and 
1 through 

record sequence number 
3) 


A-17 


8070 


A. 5. 3 

SEP RECORD 3 


Item 

Location 

Format 

1 

1-2 

12 

2 

3 

11 

3 

4 

11 


4 

5 

11 

5 

6-7 

F2.1 

6 

8-9 

P2.1 

7 

10-11 

P2.1 

8 

12-13 

P2.1 

9 

14-15 

P2.1 

10 

16-17 

P2.1 

11 

18-19 

P2.1 

12 

20-21 

P2.1 

13 

22-23 

P2.i 

14 

24-25 

P2.1 

15 

26-27 

P2.1 

16 

28-29 

P2.1 

17 

30-31 

F2.1 

18 

32-33 

P2.1 

19 

34-35 

P2.1 

20 

36-38 

F3.1 

21 

39-41 

F3.1 

22 

42-44 

F3.1 

23 

45-47 

F3.1 


Description 

Project code from ENCODE. HDR 

Record sequence number 

Status flag for the 
Complexity of Problem (CP) 
measure: 

■ 1, unchecked 

■ 2 , hand checked 

■3# verified by application 

Evaluation code for the CP 
measure 

CONSTRAINT 

Memory 

Timing 

Amount of data in step 
Data base size 
Number of data sets 
COMMUNICATIONS 

Number of program's. 

Number of subsystems 
Number of data sets 
Use of old code • 

New algorithms 
Schedule 
Not defined 
Not defined 
Not defined 
Not defined 
SUMS 

Items 5 and 6 
Items 7 through 9 
Items 10 through 12 
Items 13 through 15 


A-18 
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Item 

Location 

Format 

24 

48-50 

F3.1 

25 

51 

11 


26 

52 

II 

27 

53-54 

F2.1 

28 

55-56 

F2.1 

29 

57-58 

F2.1 

30 

59-60 

F2.1 

31 

61-62 

F2.1 

32 

63-64 

F2.1 

33 

65-66 

F2.1 

34 

67-68 

F2.1 

35 

69-70 

F2.1 

36 

71-72 

F2.1 

37 

73-74 

F2.1 

38 

75-76 

F2.1 

39 

77-78 

F2. 1 

40 

79-80 

F2.1 

41 

81-82 

F2. 1 

42 

83-85 

F3. 1 

43 

86-88 

F3.1 

44 

89-91 

F3.1 

45 

92-94 

P3. 1 


Description 

Items 5 through 15 

Status flag for the 
Internal Influences on 
Project (IN) measure: 

■ 1, unchecked 

* 2 , hand checked 

* 3, verified by application 

Evaluation code for the IN 
measure 

OVERTIME 

Weekends 

Nights 

Early phases 

STAFFING PROBLEMS 

Design 

Turnover 

Early departure (accept- 
ance testing) 

Extra help needed 

PROJECT MANAGER 

At start 

Turnover 

At end 

Team attitude 

Project leader turnover 

Number of project 
managers/leaders 

Not defined 

Not defined 

SUMS 

Items 27 through 29 

Items 30 through 33 

Items 34 through 36, 38, 
and 39 

Items 27 through 39 


8070 


A-19 



Item 

Location 

Format 

46 

95 

11 


47 

9o 

11 

48 

97-98 

F2.1 

49 

99-100 

F2.1 

50 

101-102 

F2.1 

51 

103-104 

F2.1 

52 

105-106 

F2.1 

53 

107-108 

F2.1 

54 

109-110 

F2.1 

. 55 

111-112 

F2.1 

56 

113-114 

F2.1 

57 

115-116 

F2.1 

.58 

117-118 

F2.1 

59 

119-120 

F2.1 

60 

121-122 

F2.1 

61 

123-124 

F2.1 

62 

125-126 

F2.1 

63 

127-128 

F2.1 


64 

129-130 

F2.1 

65 

131-132 

F2.1 

66 

133-134 

F2.1 

67 

135-136 

F2. 1 


Description 

Status flag for the 
External Influences on 
Project (EX) measure: 

■ I, unchecked 

■ 2, hand checked 

■ 3, verified by application 

Evaluation code for the EX 
measure 

REQUIREMENTS 

Changes 

Completeness 

SUPPORT 

Analysis 

Misi^ion project 

Development manager 

Development leader 

OUTSIDE DEVELOPMENT 

Number of subsystems 

Frontend processors 

Ontime delivery 

SIMULATOR 

Availability 

Correctness 

Data support 

ANALYSIS LEADER 

At Start 

Turnover 

At end 

Number of analysis leaders/ 
managers 

SUPPORT 

Software 

Hardware 

Not defined 

Not defined 


A-20 
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SUMS 


Item 

Location 

Format 

68 

137-139 

P3.1 

69 

140-142 

F3.1 

70 

143-145 

F3.1 

71 

146-148 

F3.1 

72 

149-151 

F3.1 

73 

152-154 

F3.1 

74 

155-157 

F3.1 

75 

158-161 

F4.1 

76 

162-171 

AlO 


Primary key: Project code and 

(bytes 1 through 


Description 

Items 48 and 49 

Items 50 through 53 

Items 54 through 56 

Items 57 through 59 

Items 60 through 63 

Items 64 and 65 

Items 48 through 65 

Item 24*650/550, item 45, 
and item 74*650/900 

Spares 

record sequence number 
3) 


A- 21 
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A. 5. 4 SEP RECORD 4 


Item 

Location 

Format 

1 

CM 

1 

12 

2 

3 

11 

3 

4 

11 


4 

5 

11 

5 

6-7 

F2.1 

6 

8-9 

P2.1 

7 

10-11 

F2.1 

8 

12-13 

F2.-1 

9 . 

14-15 

F2.1 

10 

16-17 

F2.1 

11 

18-19 

F2.1 

12 

20-21 

F2.1 

13 

22-23 

F2.1 

14 

24-25 

F2.1 

15 

26-27 

F2.1 

16 

28-29 

P2.1 

17 

30-31 

F2.1 

18 

32-33 

P2.1 

19 

34-35 

P2.1 

20 

36-37 

P2.1 

21 

38-39 

F2.1 

22 

40-41 

P2.1 


Description 

Project code from ENCODE. HDR 

Record sequence number 

Status flag for the 
Resources Available (RA) 
measure: 

« 1, unchecked 
• 2 , hand checked 
> verified by application 

Evaluation code for the RA 
measure 

DEVELOPMENT PROCESS 
Formal training 
informal training 
Documentation 
SUPPORT SOFTWARE 
Instruction 
Maintenance 
Simulator 
COMPUTER SUPPORT 
Model 75 
Model 95 
Other model 
RJP 
TSO 
OPS 
Space 

Graphic device 
Not defined 
PERSONNEL 
Librarian 
Dedicated expert 
IV & V team 


A-22 
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Item 

Location 

Forma 

23 

42-43 

P2.1 

24 

44-45 

F2.1 

25 

46-48 

F3.1 

26 

49-51 

F3.1 

27 

52-54 

F3.1 

28 

55-57 

F3.1 

29 

58-60 

F3.1 

30 

61 

11 


31 

62 

11 

32 

63-64 

F2.1 

33 

65-66 

F2.1 

34 

67-68 

F2.1 

35 

69-70 

F2.1 

36 

71-72 

F2.1 

37 

73-74 

F2.1 

38 

75-76 

F2.1 

39 

77-78 

F2.1 

40 

79-80 

F2.1 

41 

81-82 

F2.1 

42 

83-84 

F2.1 

43 

85-86 

F2.1 

44 

87-88 

F2.1 

45 

89-90 

F2. 1 

46 

91-92 

F2.1 


Deacr iptlon 

Not defired 
Not defined 
SUMS 

Items 5 through 7 
Items 8 through 10 
Items 11 through 18 
Items 20 through 22 
Items 25 through 28 

Status flag for the 
Software Product (PR) 
measure: 

» 1, unchecked 

» 2t hand checked 

* 3, verified by application 

Evaluation code for the PR 
measure 

Cost of« project 
Timeliness of completion 
Confidence in product 
SIZE 

New software 

Extensively modified soft- 
ware 

Slightly modified software 
Old software 
Readable 

Reliable documentation 
COMPLETENESS 
Design 
Code 
Testing 

MEET REQUIREMENTS 
Processing 
Memory 
Not defined 


8070 
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Item 

Location 

Format 

47 

93-94 

F2.1 

48 

95-96 

F2.1 

49 

97-98 

F2.1 

50 

99-100 

F2.1 

51 

101-102 

F2.1 

52 

103-105 

F3.1 

53 

106-108 

F3.1 

54 

109-111 

F3.1 

55 

112-114 

F3.1 

5S 

115 

11 


5»7 

116 

11 

58 

117-118 

F2.1 

59 

119-120 

P2.1 

60 

121-122 

F2.1 

61 

123-124 

F2.1 

62 

125-126 

F2.1 

63 

127-128 

F2.1 

64 

129-130 

F2.1 

65 

131-132 

P2.1 

66 

133-134 

P2.1 

67 

135-136 

P2.1 

68 

137-138 

P2.1 

69 

139-140 

P2.1 

70 

141-142 

P2.1 

71 

143-144 

P2.1 


Description 

Not defined 
Not defined 
Not defined 
Not defined 
Not defined 
SUMS 

Items 35 through 38 

Items 41 through 43 

Items 44 and 45 

Items 32 through 45 

Status flag for the 
Product/Process Performance 
(PP) measure: 

« 1, unchecked 

* 2 , hand checked 

» 3r verified by application 

Evaluation code for the PP 
measure 

PRODUCT 

Reliability 

Performance 

Operational considerations 
Ease of testing 
Not defined 
Not defined 
PROCESS 

Visibility 

Planning and followthrough 

Stable schedule 

Stable with perturbations 

Timeliness of records 

Not defined 

Not defined 

Not defined 
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Item 

Location 

Format 

Description 

72 

145-146 

P2.1 

Not defined 




SUMS 

73 

147-149 

F3.1 

Items 58 through 61 

74 

150-152 

P3.1 

Items 64 through 68 

75 

153-155 

F3.1 

Items 73 and 74 

76 

156-165 

AlO 

Spares 


Primary key: Project code and record sequence number 

(bytes 1 through 3) 
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A. 5.5 
Item 

SEP RECORD 5 
Location 

Format 

Dtacr lotion 

1 

1-2 

12 

Project code from ENCODE. HDR 

2 

3 

11 

Record sequence number 

3 

4 

11 

Status flag for the Team 
Rank (RK) .neasuret 

■ 1, unchecked 

■ 2| hand checked 

■ 3r verified by application 

4 

5 

11 

Evaluation code for the RK 
measure 

5 

6-8 

F3.1 

Design - programmers 
DESIGN - TECHNICAL STAFF 

6 

9-11 

F3.1 

Programmers and project 
managers 

7 

12-14 

F3.1 

Programmers, project man- 
agers, and analysis man- 
agers 

8 

15-17 

F3.1 

Programmers and develop- 
ment managers 

DESIGN - DEVELOPMENT MANAGE- 
MENT 

9 

18-20 

F3.1 

Project 

10 

21-23 

P3.1 

Project and analysis 

11 

24-26 

F3.1 

Development 

DESIGN - INTERFACE MANAGE- 
MENT 

12 

27-29 

F3.1 

Analysis 

13 

30-32 

F3.1 

Development 

14 

33-35 

F3.1 

Design - not defined 

15 

36-38 

F3.1 

Implementation - programmers 

IMPLEMENTATION - TECHNICAL 
STAFF 

16 

39-41 

P3.1 

Programmers and project 
managers 

17 

42-44 

P3.1 

Programmers, project man- 
agers, and analysis man- 
agers 


A-26 
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Item 

Location 

Format 

18 

45-47 

F3.1 


19 

48-50 

F3.1 

20 

51-53 

F3.1 

21 

54-56 

F3.1 


22 

57-59 

F3.1 

23 

60-62 

F3.1 

24 

63-65 

F3.1 

25 

66-68 

F3.1 

26 

69-71 

F3.1 

27 

72-74 

• 

F3.1 

28 

75-77 

F3.1 


29 

78-80 

F3.1 

30 

81-83 

F3.1 

31 

84-86 

F3.1 

32 

87-89 

F3.1 

33 

90-92 

F3.1 

34 

93-95 

F3.1 

35 

96-98 

F3.1 

36 

99-101 

F3.1 

37 

102-104 

F3.1 


Dtacriptioft 

Programmers and develop - 
meat managers 

IMPLEMENTATION - DEVELOPMENT 
MANAGEMENT 

Project 

Project and analysis 
Development 

IMPLEMENTATION - INTERFACE 
MANAGEMENT 

Analysis 

Development 

Implementation - not defined 

Test - programmers 

TEST - TECHNICAL STAFF 

Programmers and project 
managers 

Pr<?grammers, project man- 
agersr and analysis man- 
agers 

Programmers and develop- 
ment managers 

TEST - DEVELOPMENT MANAGE- 
MENT 

Project 

Project and analysis 
Development 

TEST - INTERFACE MANAGEMENT 

Analysis 

Development 

Test - not defined 

Overall - programmers 

OVERALL - TECHNICAL STAFF 

Programmers and project 
managers 

Programmers, project man- 
agers, and analysis man- 
agers 


8070 


A- 27 



Item 

Location 

Format 

Description 

38 

105-107 

F3.1 

Programmers and develop- 
ment managers 




OVERALL - DEVELOPMENT MAN- 
AGEMENT 

39 

108-110 

F3.1 

Project 

40 

111-113 

F3. 1 

Project and analysis 

41 

114-116 

F3.1 

Development 




OVERALL - INTERFACE MANAGE- 
MENT 

42 

117-119 

F3.1 

Analysis 

43 

121-122 

F3.1 

Development 

44 

123-125 

F3.1 

Overall - not defined 

45 

12^ 

11 

Status flag for the Years 
of Professional Experience 
(YP) measure: 

« 1, unchecked 

» 2 , hand checked 

» 3, verified by application 

46 .. 

127 

11 

Evaluation code for the YP 
measure 

47 

128-130 

F3.1 

Design - programmers 
DEGIGN - TECHNICAL STAFF 

48 

131-133 

F3.1 

Programmers and project 
managers 

49 

134-136 

F3.1 

Programmers, project man- 
agers, and analysis man- 
agers 

50 

137-139 

P3.1 

Programmers and develop- 
ment managers 




DESIGN - DEVELOPMENT MANAGE- 
MENT 

51 

140-142 

P3.1 

Project 

52 

143-145 

F3.1 

Project and analysis 

53 

146-148 

F3.1 

Development 




DESIGN - INTERFACE MANAGE- 
MENT 

54 

149-151 

F3.1 

Analysis 


A-28 




1 


8070 


Item 

Location 

Format 

55 

152-154 

F3.1 

56 

155-157 

F3.1 

57 

158-160 

F3.1 

58 

161-163 

F3.1 

59 

164-166 

F3.1 

60 

167-169 

F3.1 

61 

170-172 

F3.1 

62 

173-175 

F3.1 

63 

176-178 

F3.1 

64 

179-181 

F3.1 

65 

182-184 

F3.1 

66 

185-187 

F3.1 

67 

188-190 

F3.1 

68 

191-193 

F3.1 

69 

194-196 

F3.1 

70 

197-199 

F3.1 


71 

200-202 

F3.1 

72 

203-205 

P3.1 

73 

206-208 

F3.1 


Description 

Development 

Design - Not defined 

Implementation - programmers 

IMPLEMENTATION - TECHNICAL 
STAIfF 

Programmers and project 
managers 

Programmers, project man- 
agers, and analysis man- 
agers 

Programmers and .develop- 
ment managers 

IMPLEMENTATION - DEVELOPMENT 
MANAGEMENT 

Project 

Project and analysis 
. Development 

IMPLEMENTATION - INTERFACE 
MANAGEMENT 

Analysis 

Development 

Implementation - not defined 

Test - programmers 

TEST - TECHNICAL STAFF 

Programmers and project 
managers 

Programmers, project man- 
agers, and analysis man- 
agers 

Programmers and develop- 
ment managers 

TEST - DEVELOPMENT MANAGE- 
MENT 

Project 

Project and analysis 
Development 


A-29 


8070 



Item 

Location 

Format 

Description 




- INTERFACE MANAGEMENT 

74 

209-211 

F3.1 

Analysis 

75 

212-214 

F3.1 

Development 

76 

215-217 

F3.1 

Test - not defined 

77 

218-220 

F3.1 

Overall - programmers 
OVERALL - TECHNICAL STAFF 

78 

221-223 

F3.1 

Programmers and project 
managers 

79 

224-226 

F3.1 

Programmers r project man- 
agers, and analysis man- 
agers 

80 

227-229 

F3.1 

Programmers and develop- 
ment managers 

OVERALL - DEVELOPMENT MAN- 
AGEMENT 

81 

230-232 

F3.1 

Project 

82 

233-235 

F3.1 

Project and analysis 

83 

236-238 

F3.1 

Development 

OVERALL - INTERFACE MANAGE-* 
MENT 

84 

239-241 

F3.1 

Analysis 

85 

242-244 

F3.1 

Development 

86 

245-247 

P3.1 

Overall - not defined 

87 

248 

11 

Status flag for the years 
of Applicable Experience 
(YA) measure: 

» 1, unchecked 

« 2, hand checked 

» 3, verified by application 

88 

249 

11 

Evaluation code for the YA 
measure 

89 

250-252 

F3.1 

Design - programmers 
DESIGN - TECHNICAL STAFF 

90 

253-255 

F3.1 

Programmers and project 
managers 

91 

256-258 

F3.1 

Programmers, project man- 
agers, and analysis man- 
agers 


A-30 


8070 


Item Location Format 


Description 


92 

259-261 

F3.1 

Programmers and develop- 
ment managers 




DESIGN - DEVELOPMENT MANAGE- 
MENT 

93 

262-264 

P3.1 

Project 

94 

265-267 

F3.1 

Project and analysis 

95 

268-270 

F3.1 

Development 




DESIGN - INTERFACE MANAGE- 
MENT 

96 

271-273 

F3.1 

Analysis 

97 

274-276 

F3.1 

Development 

98 

277-279 

F3.1 

Design - not defined 

99 

280-282 

F3.1 

Implementation - programmers 




IMPLEMENTATION - TECHNICAL 
STAFF 

100 

283-285 

F3.1 

Programmers and project 
managers 

101 

286-288 

F3.1 

Programmers*, project man- 
agers, and analysis man- 
agers 

102 

289-291 

F3.1 

Programmers and develop- 
ment managerr. 




IMPLEMENTATION - DEVELOPMENT 
MANAGEMENT 

103 

292-294 

F3.1 

Project 

104 

295-297 

P3.1 

Project and analysis 

105 

298-300 

F3.1 

Development 




IMPLEMENTATION - INTERFACE 
MANAGEMENT 

106 

301-303 

F3.1 

Analysis 

107 

304-306 

F3.1 

Development 

108 

307-309 

P3. 1 

Implementation - not defined 

109 

310-312 

P3.1 

Test - programmers 
TEST - TECHNICAL STAFF 

110 

313-315 

F3.1 

Programmers and project 


managers 


A-31 
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Item 

Location 

Format 

Descr iption 

111 

316-318 

F3.1 

Programmers, project man- 
agers, and analysis man- 




agers 

112 

319-321 

F3.1 

Programmers and develop- 


ment managers 


TEST - DEVELOPMENT MANAGE- 
MENT 


113 

322-324 

F3.1 

Project 

114 

325-327 

F3.1 

Project and analysis 

115 

328-330 

F3.1 

Development 

TEST - INTERFACE MANAGEMENT 

116 

331-333 

F3.1 

Analysis 

117 

334-336 

F3.1 

Development 

118 

337-339 

F3.1 

Test - not defined 

119 

340-342 

F3.1 

Overall - programmers 
OVERALL - TECHNICAL STAFF 

120 

343-345 

F3.1 

Programmers and> project 
managers 

121 

346-348 

F3.1 

Programmers, project man- 
agers, and analysis man- 
agers 

122 

349-351 

F3.1 

Programmers and develop- 
ment managers 


OVERALL - DEVELOPMENT MAN- 
AGEMENT 


123 

352-354 

F3.1 

Project 

124 

355-357 

F3.1 

Project and analysis 

125 

358-360 

F3.1 

Development 




OVERALL - INTERFACE MANAGE 
MENT 

126 

361-363 

F3.1 

Analysis 

127 

364-366 

F3.1 

Development 

128 

367-369 

F3.1 

Overall - not defined 

129 

370 

11 

Status flag for the Years 
of Environment Experience 


(YE) measure: 
s 1, unchecked 
= 2 , hand checked 
= 3, verified by application 

A-32 


8070 



Item 

Location 

Format 

Description 

130 

371 

11 

Evaluation code for the YE 
measure 

131 

372-374 

P3.1 

Design - programmers 
DESIGN - TECHNICAL STAFF 

132 

375-377 

F3.1 

Programmers and project 
managers 

133 

378-380 

F3.1 

Programmers, project man- 
agers, and analysis man- 
agers 

134 

381-383 

F3.1 

Programmers and develop- 
ment managers 




DESIGN - DEVELOPMENT MANAGE- 
MENT 

135 

384-386 

F3.1 

Project 

136 

387-389 

F3.1 

Project and analysis 

137 

390-392 

F3.1 

Development 




DESIGN - INTERFACE MANAGE- 
MENT 

138 

393-395 

F3.1 

Analysis 

139 

396-398 

F3.1 

Development 

140 

399-401 

F3.1 

Design - not defined 

141 

402-404 

F3.1 

Implementation - programmers 




IMPLEMENTATION - TECHNICAL 
STAFF 

142 

4C5-407 

F3.1 

Programmers and project 
managers 

143 

408-410 

F3.1 

Programmers, project man- 
agers, and analysis man- 
agers 

144 

411-413 

F3.1 

Programmers and develop- 
ment managers 




IMPLEMENTATION - DEVELOPMENT 
MANAGEMENT 

145 

414-416 

P3.1 

Project 

146 

417-419 

F3.1 

Project and analysis 

147 

420-422 

F3.1 

Development 
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Item 


148 

149 

150 

151 

152 

153 

154 


155 

156 

157 

158 

159 

160 
161 

162 

163 

164 


165 

166 
167 


Location 

Format 

Description 



IMPLEMENTATION - INTERFACE 
MANAGEMENT 

423-425 

F3.1 

Analysis 

426-428 

F3.1 

Development 

429-431 

F3.1 

Implementation - not defined 

432-434 

F3.1 

Test - programmers 
TEST - TECHNICAL STAFF 

435-437 

F3.1 

Programmers and project 
managers 

438-440 

F3.1 

Programmers, project man- 
agers, and analysis man- 
agers 

441-443 

F3.1 

Programmers and develop- 
ment managers 



TEST - DEVELOPMENT MANAGE- 
MENT 

444-446 

F3.1 

Project 

447-449 

F3.1 

Project and analysis 

450-452 

F3.1 

Development 



TEST - INTERFACE MANAGEMENT 

453-455 

F3.1 

Analysis 

456-458 

P3.1 

Development 

459-461 

F3.1 

Test - not defined 

462-464 

F3.1 

Overall - programmers 
OVERALL - TECHNICAL STAFF 

465-467 

F3.1 

Programmers and project 
managers 

468-470 

F3.1 

Programmers, project man- 
agers and analysis man- 
agers 

471-473 

F3.1 

Programmers and develop- 
ment managers 



OVERALL - DEVELOPMENT MAN- 
AGEMENT 

474-476 

F3.-^ 

Project 

477-479 

F3.1 

Project and analysis 

480-482 

F3.1 

Development 
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Item 

Location 

Format 

Description 




OVERALL - INTERFACE MANAGE 
MENT 

168 

483-485 

P3.1 

Analysis 

169 

486-488 

P3.1 

Development 

170 

489-491 

P3.1 

Overall - not defined 

171 

492-501 

AlO 

Spares 

Primary 

key: Project 

(bytes 

code and 
1 through 

record sequence number 
3) 


8070 
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A. 5. 6 
Item 

SEP RECORD 6 
Location 

Format 

Description 

1 

1-2 

12 

Project code from ENCODE. HDR 

2 

3 

11 

Record sequence number 

3 

4 

11 

Status flag for the 
Walston-Felix Model (WP) 
measure: 

• 1, unchecked 

« 2 , hand checked 

■ 3, verified by application 

4 

5 

11 

Evaluation code for the WF 
measure 

5 

6-7 

F2.1 

Experience with application 

6 

8-9 

P2.1 

Participation in 
requirements definition 

7 

10-11 

F2.0 

Percentage of programmers 
in design 

PROGRAMMERS ' 

8 

12-13 

P2.1 

Qualifications 

9 

14-15 

P2. 1 

Familiarity with machine 

10 

16-17 

P2.1 

Familiarity with language 

11 

18-19 

P2. 1 

Familiarity with graphics 

12 

20-21 

F2.1 

Familiarity with applica- 
tion 

13 

22-23 

F2.1 

Degree to which personnel 
worked together 

14 

24-25 

F2.1 

Not defined 

15 

26-27 

F2.1 

Customer participation in 
requirements definition 

16 

28-29 

F2.1 

Customer interface 

17 

30-31 

F2.1 

Customer-originated design 
changes 

18 

32-33 

F2.1 

Application processing 

19 

34-35 

P2.1 

Program flow 

20 

36-37 

F2.1 

Interprogram communications 

21 

38-39 

F2.1 

External communications 
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Item 

Location 

Format 

22 

40-41 

F2.1 

23 

42-43 

P2.1 

24 

44-45 

F2.1 

25 

46-47 

P2.1 

26 

48-49 

F2.1 

27 

50-51 

P2.0 

28 

52-53 

P2.1 

29 

54-55 

F2.1 

30 

56-57 

F2.1 

31 

58-59 

F2.1 

32 

60-61 

P2.1 

33 

62-63 

P2.1 

34 

64-65 

P2.1 

35 

66-68 

P3.1 

36 

69-71 

P3.1 

37 

72-74 

F3.1 

38 

75-77 

F3.1 

39 

78-80 

P3.1 


40 

81-83 

P3.1 

41 

84-86 

F3.1 

42 

87-89 

P3.1 

43 

90-92 

P3.1 

44 

93-95 

F3.1 

45 

96-98 

F3.1 

46 

99-101 

F3.1 

47 

102-104 

F3.1 

43 

105-107 

F3.1 


D escription 

Data base structure 

Percentage of coder 
real-time or graphics 

Storage constraint 

Timing constraint 

I/O constraint 

Items in data base 

Hardware under development 

Unclassified 

Not defined 

Not defined 

Not defined 

Not defined 

Not defined 

PERCENTAGE OP DEVELOPMENT 
On IBM S/360-95 
On IBM S/360-75 
At STL 

Percentage of programmers 
in design 

Percentage of previous 
personnel interactions 

PERCENTAGE OF ENVIRONMENT 

' Closed 

Open with respect 

Open 

RJE 

TSO 

PERCENTAGE OF CODE 
Structured 
Read 

Developed top-down 
Via chief programmer 
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Item 

Location 

Format 

49 

108-110 

F3.1 

50 

111-113 

F3.1 

51 

114-116 

F3.1 

52 

117-119 

F3.1 

53 

120-122 

F3.1 

54 

123-125 

F3.1 

55 

126-130 

F5.2 

56 

131-135 

F5.2 

57 

136-138 

F3.1 

58 

139-141 

F3.1 

59 

142-144 

F3.0 

60 

145-147 

13 

61 

148-150 

13 

62 

151-153 

13 

63 

154-156 

13 

64 

157-159 

13 

65 

160-162 

F3.1 

66 

163-165 

F3.1 

67 

166-168 

F3.1 

68 

169-171 

F3.1 

69 

172-174 

F3.1 

70 

175-177 

P3.1 

71 

178-.1?I3 

16 

72 

18i-i3'i 

16 

73 

190-195 

16 

74 

196-201 

16 


De»cr iption 

PERCENTAGE OF EFFORT 
Management 
Administration 
Programmers 
Analysts 
Operators 
Others 

Total staff -months 

Total cost in programmer 
units (staff-months) 

Not defined 

Percentage of schedule to 
complete acceptance testing 
(actual workweeks) 

Total weeks to complete 
project (workweeks) 

Not defined 

Not defined ' 

Not defined 

Not defined 

Not defined 

PERCENTAGE OF CODE 

Nonmathematical and I/O 
formatting 

Mathematical and compu- 
tational 

CPU and I/O control 
Fallback and recovery 
Other 

Real-time or graphics 
DEVELOPED LINES 
Of ALC 
Of macros 
Of FORTRAN 

Total developed lines 
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Item 

Location 

Format 

75 

202-207 

16 

76 

208-213 

16 

77 

214-219 

16 

78 

220-225 

16 

79 

226-229 

14 

80 

230-233 

14 

81 

234-237 

14 

82 

238-241 

14 

83 

242-245 

14 

84 

246-249 

14 

85 

250-252 

F3.1 

86 

253-255 

F3.1 

87 

258 

11 


88 

257 

11 

89 

258-260 

F3.1 

90 

261-263 

F3.1 

91 

264-266 

F3.1 

92 

267-269 

P3.1 

93 

270-272 

P3.1 

94 

273-275 

F3.1 

95 

276-278 

F3.1 

96 

279-281 

F3.1 


Dtscr Iption 

DELIVERED LINES 
Of ALC 
Of macros 
Of FORTRAN 

Total delivered lines 
Items in data base 
Pages of documentation 
Not defined 
Not defined 
Not defined 
Not defined 
SUMS 

Items 5 through 13 

Items 15 through 29 

Status flag for the 

PRICE S3 Model (PS) measure: 

* 1, unchecked 

• 2 , hand checked 

■ 3 , verified by application 

Evaluation code for the PS 
measure 

PERCENTAGE OF SCHEDULE 

Design phase (from start) 

Design activity (from 
start) 

Coding phase (from design 
phase) 

Coding activity (from de- 
sign phase) 

Test phase (from coding 
phase) 

Test activity (from docu- 
mentation phase) 

System documentation phase 
(from end) 

Documentation activity 
(from end) 
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Item 

Location 

Format 

Description 

97 

282-285 

F4.3 

Ratio of actual schedule 


to 67-weelc schedule 
COMPLEXITY FACTOR 


98 

286-288 

F3.2 

Total 

99 

289-291 

F3.2 

Personnel only 

100 

292-294 

P3.2 

Product only 

101 

295-297 

F3.2 

External effects only 

102 

298-300 

F3.1 

New design - percentage of 
code in wholly new 
components 

103 

301-303 

F3.1 

New code - percentage of 
code in new and extensively 
modified components 

104 

304-306 

P3.1 

New test - percentage of 
code in new or modified 
components 

105 

307-309 

• 

P3.2 

Application - instruction 
mix 

•m 

106 

310-312 

P3.2 

• 

Resource - skill mix and 
experience for cost 

107 

313-315 

P3.2 

Utility - fraction of 
storage and timing capacity 

108 

316-318 

P3.2 

Platform - strictness of 
standards, e.g., MIL-Spec 

109 

319-321 

P3.2 

Sum items 98 through 101 

110 

322 

11 

Status flag for the COCOMO 
Model (CO) measure: 

■ 1, unchecked 

• 2, hand checked 

« 3, verified by application 

111 

323 

11 

Evaluation code for the CO 
measure 




PRODUCT 

112 

324-326 

P3.2 

Required software relia- 
bility 

113 

327-329 

P3.2 

Data base size 

114 

330-332 

F3.2 

Product complexity 
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Item 

Location 

Format 

IIS 

333-335 

P3.2 

116 

336-338 

F3.2 

117 

339-341 

F3.2 

118 

342-344 

F3.2 

119 

345-347 

F3.2 

120 

348-350 

F3.2 

121 

351-353 

F3.2 

122 

354-356 

F3.2 

123 

357-359 

F3.2 

124 

360-362 

F3.2 

125 

363-365 

F3.2 

126 

366-368 

F3.2 

127 

369-378 

AID 

Primary 

key: Project 

(bytes 

code and 
1 through 


D>»cr iption 

COMPUTER 

Execution timt constraint 

Main storage constraint 

Virtual machine volatility 

Computer turnaround time 

PERSONNEL 

Analyst capability 

Applications experience 

Programmer capability 

Virtual machine experience 

Programming language ex- 
perience 

PROJECT 

Use of modern programming 
practices 

Use of software tools 

Required development 
schedule 

Spares 

record sequence number 
3) 
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A. 5. 7 

SEP RECORD 7 


Item 

Location 

Format 

1 

1-2 

12 

2 

3 

11 

3 

4 

11 


4 

5 

11 

5 

6-7 

F2.0 

6 

8-9 

P2.0 

7 

10-11 

F2.0 

8 

12-13 

P2.0 

3 

14-1>5 

F2..0 

10 

16-17 

F2.0 

11 

18-21 

14 

12 

22-25 

14 

13 

26-29 

14 

14 

30-33 

14 

15 

34-35 

P2.0 

16 

36-37 

F2.0 

17 

38-39 

P2.0 

18 

40-41 

F2.0 

19 

42-43 

F2.0 

20 

44-45 

F2.0 

21 

46-49 

14 

22 

50-53 

14 


Description 

Project code from ENCODE. HDR 

Record sequence number 

Status flag for the 
Miscellaneous (MS) measure: 

■ 1, unchecked 

« 2, hand checked 

» 3, verified by application 

Evaluation code for the MS 
measure 

PRODUCT 

Number of programs 
Number of subsystems 
DATA SETS 
Input 

Input/output 
Output 
Total 
DATA BASE 
Input 

Xnput/output 

Output 

Total 

PROCESSING 

Number qL programs 
Number of subsystems 
DATA SETS 
Input 

Input/output 
Output 
Total 
DATA BASE 
Input 

Input/output 
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Item 

Location 

Format 

Description 

23 

54-57 

14 

Output 

24 

58-61 

14 

Total 

DOCUMENTATION 

25 

62-65 

14 

Pages of design document 

26 

66-69 

14 

Pages of test plan 

27 

70-73 

14 

Pages of user's guide/ 
system description 

28 

74-77 

14 

Pages of prologs 

29 

78-82 

15 

Total pages 
AVERAGE STAFF 

30 

83-85 

P3.1 

Programmers 

3i 

86-88 

F3.1 

Programmers and managers 

32 

89-91 

F3.1 

All personnel 

33 

92-95 

14 

Not defined 

34 

96-99 

14 

Not defined 

35 

100-103 

14 

Not defined 

36 

104-107 

14 

Not defined 

37 

‘ 108-111 

14 

Not defined 

38 

112-115 

14 

Not defined 

39 

116-119 

I'vi 

Not defined 

40 

120-123 

14 

Not defined 

41 

124-127 

14 

Not defined 

42 

128-131 

14 

Not defined 

43 

132-135 

14 

Not defined 

44 

136-139 

14 

Not defined 

45 

140 

11 

Status flag for the Code 
Breakdown (SW) measure: 

* 1, unchecked 

« 2 , hand checked 

» 3, verified by applicati?! 

46 

141 

11 

Evaluation code for the SW 
measure 

BASELINE DIAGRAM COMPONENTS 

47 

142-145 

14 

New 

48 

146-149 

14 

Extensively modified 
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Item 


Location 


Format 


49 

150-153 

14 

50 

154-157 

14 

51 

158-161 

14 

52 

162-165 

14 

53 

166-169 

14 

54 

170-173 

14 

55 

174-177 

14 

56 

178-181 

14 

57 

182-187 

16 

58 

188-193 

16 

59 

194-199 

16 

60 

200-205 

16 

61 

206-211 

16 

62 

212-217 

16 

63 

218-223 

16 

64 

224-229 

16 

65 

230-235 

16 

66 

236-241 

16 

67 

242-247 

16 

68 

248-253 

16 

69 

254-259 

16 

70 

260-265 

16 

71 

266-271 

16 

72 

272-277 

16 

73 

278-283 

16 

74 

284-289 

16 

75 

290-295 

16 

76 

296-301 

16 


Deacrlption 

Slightly modified 

Old 

Total 

DECISION MODULES 
New 

Extensively modified 
Slightly modified 
Old 
Total 
LOG ALC 
New 

Extensively modified 
Slightly modified 
Old 
Total 

LOG MACROS 
New 

Extensively modified 
Slightly modified 
Old 
Total 

LOG FORTRAN 
New 

Extensively modified 
Slightly modii.ied 
Old 
Total 
LOG TOTAL 
N<»w 

Extensively modified 
Slightly modified 
Old 
Total 
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Item 

Location 

Format 

77 

302-307 

16 

78 

308-313 

16 

79 

314-319 

16 

80 

320-325 

16 

81 

326-331 

16 

82 

332-337 

16 

83 

338-343 

16 

84 

344-349 

16 

85 

350-355 

16 

86 

356-361 

16 

87 

362-367 

16 

88 

368-373 

16 

89 

374-379 

16 

90 

380-385 

16 

91 

386-391 

16 

92 

392-397 

16 

93 

398-403 

16 

94 

404-409 

16 

95 

410-415 

16 

96 

416-421 

16 

97 

422-426 

15 

98 

427-431 

15 

99 

432-436 

15 

100 

437-441 

15 

101 

442-446 

15 

102 

447-451 

15 

103 

452-456 

15 


8070 


Description 

EXECUTABLE ALC 
New 

Extensively modified 
Slightly modified 
Old 
Total 

EXECUTABLE MACROS 
New 

Extensively modified 
Slightly modified 
Old 
Total 

EXECUTABLE FORTRAN 
New 

Extensively modified 
Slightly modified 
Old 
Total 

EXECUTABLE TOTAL 
NSW 

Extensively modified 
Slightly modified 
Old 
Total 
DECISIONS 
New 

Extensively modified 
Slightly modified 
Old 
Total 

LIBRARY CHANGES 
New 

Extensively modified 

A-45 



Item 

Location 

Forma 

104 

457-461 

15 

105 

462-466 

15 

106 

467-471 

15 

107 

472-475 

14 

108 

476-479 

14 

109 

480-483 

14 

110 

484-487 

14 

111 

488-491 

14 

112 

492-495 

14 

113 

496-499 

14 

114 

500-503 

14 

115 

504-507 

14 

116 

508-511 

14 

117 

512-513 

F2.0 

118 

514-515 

P2.0 

119 

516-517 

F2.0 

120 

518-519 

F2.0 

121 

520-521 

F2.0 

122 

522-525 

F4.2 

123 

526-529 

F4.2 

124 

530-533 

F4.1 

125 

534-536 

F3.2 

126 

537-539 

F3.2 

127 

540-542 

F3.0 

128 

543-345 

F3.0 

129 

546-548 

F3.1 

130 

549-551 

F3.1 


Description 

Slightly modified 

Old 

Total 

SOFTWARE CHANGES 
New 

Extensively modified 
Slightly modified 
Old 
Total 

SOFTWARE ERRORS 
New 

Extensively modified 
Slightly modified 
Old 
Total 

PERCENTAGE OF COMMENTS 
New 

Extensively modified 
Slightly modified 
Old 
Total 
ERRORS 

Per 1000 LOC 

Per 1000 executable LOC 

Per 1000 decisions 

Per baseline diagram com 
ponent 

Per decision module 

DECISIONS 

Per 1000 LOC 

Per 1000 executable LOC 

Per baseline diagram com 
ponent 

Per decision module 
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Item 

Location 

Format 

Description 

131 

552-554 

P3.3 

Ratio of LOC to expanded LOC 
EXECUTABLE LOC 

132 

555-557 

P3.0 

Per 1000 LOC 

133 

558-560 

P3.1 

Per baseline diagram com- 
ponent 

134 

561-563 

P3.0 

Per decision module 

135 

564>566 

P3.2 

Data set components per 
change 

136 

567-568 

P2.0 

Percentage of errors in 
changes 

137 

569-578 

AlO 

Spares 

Primary 

key: Project 

(bytes 

code and 
1 through 

record sequence number 
3) 
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A. 6 SUBJECTIVE EVALUATIONS DIRECTORY (DIR) FILE 


Item 

Location 

Format 

Description 


1 

1-4 

A4 

Code 


2 

5-12 

A8 

Name (measure) 


3 

13-18 

16 

Minimum value 


4 

19-24 

16 

Maximum value 


5 

25 

11 

Data record sequence 
(1 through 7) 

number 

6 

26-28 

13 

Byte location in data 

record 

7 

29-100 

72A1 

Verbal description of 
measure 

the 


Primary key: Code (bytes 1 through 4) 

Secondary key: Name (bytes 5 through 12) 
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A. 7 ATTITUDE MAINTENANCE CHAW'3E REPORT (ATM) FILE 


Item 

Location 

Format 

1 

1-6 

A6 

2 

7-8 

12 

3 

9-14 

16 

4 

15-20 

16 

5 

21 

A1 

6 

22-23 

12 

7 

24-38 

13 


8 

39 

A1 

9 

40 

A1 

10 

41 

A1 

11 

42 

A1 

12 

43 

A1 

13 

44 

A1 

14 

45 

A1 

15 

46 

A1 


16 

47 

A1 

17 

48 

A1 

18 

49 

A1 

19 

50 

A1 

20 

51 

A1 

21 

52 

A1 


Description 

Form number 

Project code from 
ENCODE. HDR 

Form date (YYMMDD) 

Date change determined 
to be necessary (YYMMDD) 

Description comment flag: 

« T, true 

* F, false 

Number of components 
changed 

Component codes from CIF: 

* T, true 

* F, false 

TYPE OP CHANGE (nonerrors 
only) 

Requirements 

New information or data 

Specification 

Design 

Hardware environment 
Software environment 
Optimization 
Other 

ERROR DETECTION ACTIVITIES: 
s* D, detection 
» 1, isolation 
= B, both 

Normal use 

Test runs 

Code reading 

Reading documentation 

Trace/dump 

Cross-reference/attitude 

list 
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Item 


Location 


Format 



22 

53 

A1 

System error messages 

23 

54 

A1 

Project-specific error 
message 

24 

55 

A1 

Other 

25 

56 

11 

Primary error type from 
ENCODE. HDRs 


■ 1, requirements error 
« 2, design error 

■ 3, error translating de- 

sign or specifications 
to code 

■ 4, specifications error 
> 5, clerical error 

■ 6, other 

■ 7, no response 


26 

57 

A1 

Related to previous change 
» Y, yes 
■ N, no 

« Cf can’t tell 
» blank, no response 

27 

58-62 

15 

Programmer code from 
ENCODE. HD R 

28 

63-68 

16 

Change start date (YYMMDD) 

29 

69 

11 

Time spent on change: 
» 1, less than 1 day 

* 2, 1 day to 1 week 
» 3, more than 1 week 

* 4, no response 

30 

70 

11 

Status flag: 

B 1, unchecked 
B 2, hand checked 
» 3, verified by applica- 
tion 

31 

71 

Al 

Comment flag: 
B Y, yes 
B N, no 

32 

72-77 

A6 

Spares 

Primary 

key: Form 

number (bytes 

1 through 6) 


it 


80 70 
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A. 8 CHANGE REPORT FORM (CRF) FILE 


Item 

Location 

Format 

Description 

1 

1-6 

A6 

Form number 
(e.g.r D00633) 

2 

7-8 

12 

Project code from 
ENCODE. HDR 

3 

9-13 

15 

Programmer code from 
ENCODE. HDR 

4 

14-19 

16 

Form date (YYMMDD) 

5 

20-21 

12 

Number of components 
changed (may be 
greater than 5) 

6 

22-23 

12 

Number of components 
examined 

7 

24 

11 

More than one com- 
ponent affected: 

- y, yes 

■ Nr no 

■ blank# no response 

8 

25-30 

T6 

Date change was deter- 
mined to be necessary 
(YYMMDD) 

9 

31-36 

16 

Date change started 
(YYMMDD) 

10 

37 

11 

Effort for change from 
ENCODE. HDR: 

B 1 , less than 1 hour 
*> 2# 1 hour to 1 day 
« 3# 1 day to 3 days 
» 4# over 3 days 
» blank# no response 

11 

38-41 

4A1 

Type of change (up to 
4 responses# from 
ENCODE. HDR) : 

» 1# error correction 
» 2# planned enhance- 
ment 

* 3# implement require- 

ments change 

* 4# improve clarity 

» 5# improve user serv- 
ice 

« 6# develop utility 
only 


8070 
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Item 

Location 

Format 

Description 




« 7, optimization 
« 8, adapt to environ- 
mental change 
■ 9, other 

« blank, no response 

12 

42-56 

513 

Codes of changed com- 
ponents from CIF 

13 

57-60 

411 

Type of error (up to 4 


responses, from 
ENCODE. HDR) : 

■ 1, requirements in- 

correct 

«• 2, functional speci- 
fications incor- 
rect 

■ 3, design error of 

several components 

■ 4, design error of 

one component 
« 5, misunderstanding 
of external en- 
vironment 

■ 6, error in language 

use 

«* It clerical error 

* 8, other 

» blank, no response 

14 61 Zl When error entered 

system from ENCODE. HDR: 
» 1, requirements 
« 2, functional speci- 
fication 
« 3, design 
> 4, code am\ test 

* 5, other 

* 6, can't tell 

« blank, no response 


15 

62 

A1 

Data structure error 




* X, yes 
« blank, no 

16 

63 

Ai 

Control logic error: 
* X, yes 
> blank, no 
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17 ACTIVITIES USED TO ISO- 

LATE ERROR (up to 5 
responses, each from 
ENCODE. HDR) : 

■ 1, preacceptance test 

- 2, acceptance test 

- 3, postacceptance 

test 

■ 4, inspection of out- 

put 

« 5, code reading by 
programmer 

■ 6, code read by 

another 

« 7, talk with other 
programmers 

■ 8, special debug code 
• 9f system error mes- 
sage 

» A, prc ject-specif ic 
error message 

■ B, reading documenta- 

tion 

■ C, trace 

■ D, dump 

■ E, cross-reference 

■ F, proof technique 

■ G, other 



64-68 

5A1 

« blank, no response 
For -program validation 


69-73 

5A1 

For detection symptoms 


74-78 

5A1 

Tried in finding cause 


79-83 

5A1 

For finding cause 

18 

84 

11 

Time to isolate error 

19 

85 

A1 

from ENCODE. HDR: 

» 1, less than 1 hour 
* 2, 1 hour to 1 day 
« 3, more than 1 day 
■ 4, never found 
« blank, no response 

Workaround used: 


* Y, yes 
■ N, no 

» blank, no response 
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Item 

Location 

Format 

Description 

20 

86 

A1 

Related to previous 
change: 

■ y» yes 

■ N, no 

■ C$ can't tell 

■ blank# no response 

21 

87-91 

15 

Previous form number 
(excli’des first ch<&r- 
acter# includes lead- 
ing zeros# e.g.# 00633) 

22 

92-97 

16 

Previous form date 
(YYMMDD) 

23 

98 

A1 

Reason comment flag: 

■ Y# yes 

■ N# no 

24 

99 

Al 

Description comment 
flag: 

■ Y# yes 

■ N# no 

25 

100 

Al 

^General comment flag: 

■ Y# yes 

■ N# no 

26 

101 

11 

Status flag: 

» 1# unchecked 

■ 2# hand checked 

■ 3# verified by appli- 

cation 

Primary 

key: Form 

number (bytes 

1 through 6) 
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A. 9 

COMPONENT STATUS 

1 REPORT 

(CSR) Plf^ 

Item 

Location 

Format 

Description 

1 

1-6 

A6 

Form number 
(e.g., B00952) 

2 

7-8 

12 

Sequence number 

3 

9-10 

12 

Project code from ENCODE. HDR 

4 

II-I5 

15 

Programmer code from 
ENCODE. HDR 

5 

16-21 

16 

Form date (YYMMDD) 

6 

22-24 

13 

Component code from CIF 

7 

25-60 

9F4.I 

Work hours spent in each 
phase (in tenths) 

8 

61-68 

A8 

Other activity name 

9 

69-72 

F4.I 

Other activity work hours 
(in tenths) 

JO 

• ^ 

73 

• 

II 

Status flag: 

■ I, unchecked 

■ 2 , hand checked 

■ 3# verified by application 

II 

74 

AI 

Source of Data (Phase) flag: 
■ Rf requirements team 
« D, development team 
« Mf maintenance team 

12 

75-79 

A5 

Spares 


Primary key: 
Secondary key: 
Tertiary key: 


Form and nequence number (bytes 1 through 8) 
CowponaDnt cod# 22 through 24) 

programn.er code (bytes II through IS) 


A-55 


8070 



A. 10 

COMPONENT 

SUMMARY FORM 

(CSF) FILE 

Item 

Location 

Format 

Description 

1 

1-6 

A6 

Form number 
(e.g.r 100633) 

2 

7-8 

12 

Project code from ENCODE. HDR 

3 

9-13 

15 

Programmer filling out form 
from ENCODE. HDR 

4 

14-18 

15 

Programmer implementing com- 
ponent from ENCODE. HDR 

5 

19-24 

16 

Form date (YYMMDD) 

6 

25 

A1 

Form stage: 

■ Nr new 

- Ur under development 

■ Cr complete 

* blank r no response 

7 

26-28 

13 

Component code from CIF 

8 

29 

11 

Precision of specification 
from ENCODE. HDR: 




■ Ir very precise 

■ 2r precise 

« 3r imprecise 
* S' blank r no response 

9 

30 

A1 

• 

Complexity: 

» Er easy 
Mr moderate 

■ Hr hard 

■ blank r no response 

10 

31-33 

311 

Type of software from 
ENCODE. HDR: 

* Ir I/O processing 
« 2r algorithmic 

* 3r logic control 

» 4r systems related 
» 5r data/COMMON block 

* 6r other 

s blank r no response 

11 

34-36 

13 

Percentage of assignment 
statements 

12 

37-39 

13 

Percentage of control 
statements 
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Item 


Location 


Format 


13 

40-42 

13 

14 

43-47 

15 

15 

48-52 

15 

16 

53-57 

15 

17 

58 

A1 

18 

59 

II 


19 60-63 411 


20 

64-65 

12 

21 

66 

A1 

22 

67-68 

12 

23 

69 

A1 


Description 


Percentage of other state- 
ments 

Number of statements with- 
out comments 

Number of statements with 
comments 

Number of machine bytes 

Independent of other soft- 
ware: 

■ y, yes 
« N, no 

■ blank, no response 

Relation to other software 
(if dependent) from 
ENCODE. HDR: 

» 1, inserted at lower level 
» 2 , new driver or interface 

* 3, redesign existing com- 

ponent's 

> 4, rename existing com- 
ponents 

» » 5, regroup existing 
material 

* 6, other 

s blank, no response 

Type of addition (up to 4 
responses, from ENCODE. HDR): 
« 1, error correction 
» 2, planned enhancement 
s 3, implement requirement 
change 

= 4, improve clarity 

» 5, improve user service 

= 6, develop utility only 

» 7, optimization 

* 8, adapt to environmental 

change 
= 9, other 

* blank, no response 
Number of components called 
Not used 

Number calling this com- 
ponent 

Not used 
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1 1 om 


Uicat Ion 


Format 


^4 70-71 12 

2S 72 A1 

2b 7.?-74 12 

27 7S Al 

20 7b- 7*7 12 

2^) 78-00 13 

30 81-82 12 

31 8 3-8?) 13 


86-87 

211 

88-89 

211 

90-91 

211 

92-93 

211 

94-9f) 

2T1 


Description 

t4umber of shared components 
Not used 

Number of components de- 
scending 

Not ised 

Primary lanouaqo used from 
KNCODF.HDR: 

- 1, FORTRAN 
» 2, ASSEMBLY 

» blank, no response 

Percentaqe primary language 

Seconda'y language used from 
ENCODE. HDR: 

• 1, FORTRAN 

- 2, ASSEMBLY 

■ blank, no response 

Percentage secondary lan- 
guage 

LEVEL OF DESIGN DETAIL for 
forms ^ design {up to 
2 res> ses, from 
ENCODE. HDR) ; 

■ 1, component 

» 2, subcomponent 

■ 3, basic block segment 

■ 4, statement 

■ 5, other 

- blank, no response 
Functional 
Procedural 
English 

Formal 

Other design form 


3 3 




CONSTRAINT; 

« X, yes 
» blank, no 

I'First: Constraint present 

Second; Component meets 
constraint) 

2Al Memory space 
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Item 


Location 


Format Descr Iption 



98-99 

2A1 

Execution time 


100-101 

2A1 

Other 

34 

102-104 

13 

Number of design computer 
runs 

35 

105-107 

13 

Number of code computer runs 

36 

108-110 

13 

Number of test computer runs 

37 

111-113 

F3.1 

Computer time for design 
runs (in tenths of minutes) 

38 

114-116 

F3.1 

Computer time for code runs 
(in tenths of minutes) 

39 

117-119 

F3.1 

Computer time for test runs 
(in tenths of minutes) 

40 

120-122 

F3.1 

Effort for design (in 
tenths “'f hours) 

41 

123-125 

F3.1 

Effort for code (in tenths 
of hours) 

42 

126-128 

F3.1 

Effort for test (in tenths 
of hours) 

43 

129-134 

16 

Estimated design end date 
(YYMMDD) 

44 

135-140 

16 

Estimated code end date 
(YYMMDD) 

45 

141-146 

A1 

Estimated test end date 
(YYMMDD) 

46 

147 

A1 

Description comment flag: 
= Y, yes 
= N, no 

47 

148-162 

513 

Components called (up to 
5 codes from CIF) 

48 

163-177 

513 

Calling components (up to 
5 codes from CIF) 

49 

178-192 

513 

Shared components (up to 
5 codes from CIF) 

50 

193-207 

513 

Components affected by re- 
organization (from Sec- 
tion F, up to 5 codes, from 
CIF) 

51 

208-227 

A20 

Name of other form of design 

52 

228-247 

A20 

Constraint other name 
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Item 

Location 

Format 

Description 

53 

248 

A1 

Useful items comment flag: 

■ y, yes 

■ N, no 

54 

249 

A1 

Additional comment flag: 

■ Y, yes 

■ N, no 

55 

250 

11 

Status flag: 

» 1, unchecked 

« 2 , hand checked 

■ 3, verified by application 

Primary 

key: Form 

number 

(bytes 1 through 6) 


Secondary key: Component code (bytes 26 through 28) 
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A. 11 GENERAL PROJECT SUMMARY (GPS) FILE 
Format has not been defined. 
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A. 12 RESOURCE SUMMARY FORM (RSF) FILE 


Item 

Location 

Format 

1 

1-6 

A6 

2 

1 

OD 

12 

3 

9-10 

12 

4 

11 

A1 


5 

12-16 

15 

6 

17-22 

16 

7 

23-25 

13 

8 

26-3.1 

16 

9 

32-108 

11(13, 

F4.1) 

10 

109 

11 

11 

110 

A1 


Description 

Form number 
(e.g., C00633) 

Sequence number 

Project code from ENCODE. HDR 

Resource type: 

» M, manpower (technical 
staff and management 
work hours) 

■ C, computer (computer 
usage hours) 

» 0, other (support per- 
sonnel work hours) 

Resource code from 
ENCODE. HDR (programmer 
coder computer code, or 
service code) 

Form date (YYMMDD) 

Percentage of hours that 
are management 

Beginning date of data 
(YYMMDD) 

Resources; number of runs 
followed by number of hours 
(in tenths of hours) 

Status flag: 

* 1, unchecked 

« 2, hand checked 
» 3, verified by application 

Source of Data (Phase) flag: 

* R, requirements team 
“ D, development team 
» M, maintenance team 

Spares 


12 111-U5 A5 

Primary k«vy: 


Form and sequence number (bytes 1 through 8) 
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A. 13 

RUN ANALYSIS 

FORM (RAP) FILE 


Item 

Location 

Format 

Description 

1 

1-6 

A6 

Form number 
(e.g., J00633) 

2 

7-S 

12 

Sequence number 

3 

9-10 

12 

Project code from 
ENCODE. HDR 

4 

11-15 

15 

Programmer code from 
ENCODE. HDR 

5 

16-21 

16 

Date of run (YYMMDD) 

6 

22-23 

12 

Computer code from 
ENCODE. HDR: 




-1, any IBM S/360 
- 2, any PDP 

• 3, IBM S/360-75 

* 4, IBM S/360-75(Cl) 

* 5, IBM S/360-91 
« 6, IBM S/360-95 

• 7, PDP-11/70 

7 

24 

A1 

• 

Interactive flag: 



- 

* X, interactive 
» blank, not interactive 

8 

25-28 

11 

Run purpose from 


ENCODE. HDR: 

» I, unit test 

* 2, system test 

* 3, benchmark test 
» 4 , maintenance or 

utility 

» 5, compile, assembly, 
or link 

s 6, debug run 

* 7, other 

s blank, no response 


9 

29-30 

12 

Number of 

components 

10 

31-45 

513 

Component 

codes from CIP 

11 

46 

A1 

First-run 

indicator : 


* X, first run 

* blank, not first run 
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Item 

Location 

Format 

12 

A1 

A1 

13 

48-51 

4A1 


14 

52 

Ai 

15 

53 

• 

11 


Primary key: Form and sequence 
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Description 


Run met objectives: 

■ Y, yes 
* N# no 

■ blank, no response 

Run results (up to 4 
responses, from 
ENCODE. HDR) : 

« 1, good run 
« 2, submit error 
« 3, JCL error 
» 4, other setup error 

■ 5, hardware error 

■ 6, software error 

■ 7, compile error 
« 8, link error 

■ 9, execution error 

■ A, user-generated mes- 

sage 

« B, ran to completion 

■ blank, no response 

Comment indicator: 

■ Y, yes 
» N, no 

Status flag: 

*■ 1, unchecked 

■ 2, hand checked 

» 3, verified by applica 
tion 

number (bytes 1 through 8) 


A . 1 4 ACCOUNTING INFORMATION (ACC) FILE 


Each record contains 

totals for a 

particular 4-hour block of 

wallclock 

time. 



Item 

Location 

format 

Description 

1 

1-2 

12 

Project code from 
ENCODE. HDR 

2 

3-8 

16 

Date (YYMMDD) 

3 

9-10 

12 

Time block (4-hour 
block) Of 4f 8r 12 f 
16f or 20 hours from 
start o.f day 

4 

11-13 

13 

TSO foreground com- 
puter runs 

5 

14-16 

13 

TSO background com- 
puter runs 

6 

17-19 

13 

RJE computer runs 

7 

20-22 

13 

Card reader cqgnputer 
runs 




* "primary computer 

8 


11 

Computer code 
from ENCODE. HDR 

9 

24-28 

F5.3 

Total CPU time (in 
thousandths of 
hours) 

10 

29-33 

F5.3 

Total I/O time (in 
thousandths of 
hours) 

11 

34-36 

13 

Total number of 
computer runs 

12 

37-39 

13 

Number of runs ex- 
cluding condition 
code 0000 or SOOC 




SECONDARY COMPUTER 

13 

40 

11 

Computer code 
from ENCODE. HDR 

14 

41-45 

F5. 3 

Total CPU time (in 
thousandths of 
hours) 
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Item 

Location 

Format 

Description 

15 

46-50 

P5.3 

Total I/O time (in 


thousandths of 
hours) 


16 

51-53 

13 

Number of computer 
runs 

17 

54-56 

13 

Number or computer 
runs excluding 
condition code 0000 
or SOOC 

18 

57 

11 

Status flag: 

■ 1, unchecked 

■ 2 , hand checked 

- 3, verified by ap- 
plication 

19 

58-67 

AlO 

Spares 

rimary key: 

Date and 

time block 

(bytes 3 through 10) 
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A. 15 

COMMENT (CMT) 

FILE 


Item 

Loca^ ion 

Format 

Description 

1 

1-6 

A6 

Form number 
(e.g., D00633) 

2 

1 

00 

12 

Sequence number 

3 

9 

A1 

Comment type: 

■ Cf comment 

■ D, description 

■ R, reason 

■ useful item 

4 

10 

11 

Record continuation number 
of this comment 

5 

11-12 

12 

Project code from 
ENCODE. HDR 

6 

13 

A1 

Comment is continued: 

■ Y, yes 

■ N, no 

7 

14-.103 

A90 

Text 

8 

104 

11 

Status flag: 


• Ir unchecked 

« 2, hand checked 

* J, verified by applica- 

tion 

Primary key: Form number * sequence number + comment type -f 

record number (bytes 1 through 10) 
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A. 16 COMPONENT INFORMATION FILE (CIF) 


It»m 

Location 

Format 

Dascriotlon 

1 

1-2 

12 

Pcojact coda from 
ENCODE. HDR 

2 

3-10 

A8 

Component name 
(a. 9.# TPNAML) 

3 

11-13 

13 

Component coda 

4 

14-15 

12 

PANVALET level number 

5 

16-17 

12 

Module function from 
ENCODE. HDR 

6 

18-19 

12 

Subayatem function from 
ENCODE. HDR 

7 

20 

11 

* 

Origin from ENCODE. HDR: 

■ Ir new code 

■ 2 , extenaively modified 

old code 

■ 3 , alightly modified old 

code 

- 4 , exact copy of old code 

8 

• 21-24 

14 

Number of executable 
aource code atatementa 

9 

25-28 

14 

Number of lines of code 
with comments 

10 

29-31 

14 

Number of comment lines 

11 

32-34 

13 

Number of unique operators 
(operators and operands 
are Halstead's measures 
(Reference 4)} 

12 

35-37 

13 

Number of unique operands 

13 

38-41 

14 

Total number of operators 

14 

42-45 

14 

Total number of operands 

15 

46-48 

13 

Number of input and output 
variables from module 

16 

49-51 

13 

Number of decisions 
(McCabe's measure (Refer- 
ence 8) ) 

17 

52-54 

13 

Number of FUNCTION refer- 
ences 

18 

55-57 

13 

Number of I/O statements 
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Item 

Location 

Format 

Description 

19 

58-60 

13 

Number of assignment 
statements 

20 

61-63 

13 

'dumber of subroutine CALL 
statements 

21 

64-66 

13 

Number of FORMAT statements 

22 

67 

11 

Status flag: 

• 1, unchecked 
" 2 , hand checked 
■ 3, verified by applica- 
tion 

23 

68-80 

A13 

Spares 


Primacy key: Component name (bytes 3 through 10) 

Secondary key: Component name prefix (bytes 3 and 4) 

Tertiary key: Component code (bytes 11 through 13) 


A-69 


8070 



A. 17 

GROWTH HISTORY 

(HIS) PILE 


Item 

Location 

Format 

Description 

1 

1-2 

12 

Project code from 
ENCODE. HDR 

2 

3-8 

16 

Date (YYMMDD) 

3 

9-14 

16 

Number of lines of code 
with comments to date 

4 

15-17 

13 

Number of modules to date 

5 

18-23 

16 

Number of changes to date 

6 

24 

11 

Status flag: 

• If unchecked 
« 2, hand checked 
■ 3f verified by applica- 
tion 

7 

25-29 

A5 

Spares 


Primary key: Date (bytes 3 through 8) 
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A . 1 9 SOURCE ANALYZER PROGRAM (SAP) OUTPUT FILE 


This 

is a single 

sequential £ile. 


Item 

vocation 

Format 

Description 

1 

1-8 

A8 

Project name 
(e.g., MAGBIAS) 

2 

9-16 

A8 

Module name 

3 

17-19 

13 

Number of parameters passed 
in calling sequence 

4 

20-22 

13 

Number of comment lines 

5 

23-26 

14 

Number of exe'^utable 
statements 

6 

27-28 

12 

Number of I/O statements 

7 

29-32 

14 

Number of lines with com- 
ments 

8 

33-35 

13 

Number of unique operators 

9 

36-33 

13 

Number of unique operands 

10 

39-42 

14 

Total number of operators 

11 

4 3'- 4 6 

14 

Total number of operands 

12 

47-49 

13 

Number of IF and .IF 
statements 

13 

50-52 

13 

Number of decisions 

14 

53-55 

13 

Number of input and output 
variables to module 

15 

56-58 

13 

Number of COMMON area 
variables 

16 

59-60 

12 

Number of DO and DOWHILE 
statements 

x7 

61-63 

13 

Number of FUNCTION refer- 
ences 

18 

64-66 

13 

Number of structured 
statements 

19 

67-69 

13 

Number of variables passed 
out 

20 

70-72 

13 

Number of assignment 
statements 

21 

73-75 

13 

Number of subroutine CALL 
statements 

22 

76-78 

13 

Nr-^ber of FORMAT statements 
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A. 19 TRANSACTION PILES 


The Transaction Piles are sequential disk backup files that 
contain records of all updates made to the corresponding 
data base files, as fellows; 


Transactior. Pile 

TKANS.CRF 
TRANS. CSR 
TRANS. CSF 
TRANS. RSP 
TRANS. RAP 
TRANS. CIP 
TRANS. HIS 


Corresponding Data Base Pile 

Change Report Form Files 
Component Status Report Piles 
Component Summary Form Piles 
Resource Summary Form Files 
Run Analysis Form Piles 
component Information Files 
Growth History Piles 


Each file has a format similar to its corresponding data 
base file. The first byte indicates whether the record has 
been added, changed, or deleted (A, C, or D) . Bytes 2 
through 7 contain the date (YYMMDD) the record was ac- 
cessed. Bytes 8 through 13 are spares. Bytes 14 through 
the end of the record contain the record as stored on the 
corresponding data base file. 


For example, the CRF Files have a record length of 
101 bytes. The CRF Transaction File has a record length of 
101 + 13 » 114 bytes. All additions, changes, and deletions 
of records on any of the CRF Piles by DBAM are recorded on a 
single CRF Transaction Pile, which has the same record for- 
mat except that byte 1 will be an A, C, or D; bytes 2 
through 7 contain the date? and bytes 8 through 13 are blank. 
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APPENDIX B - SAMPLE DATA COLLECTION FORMS 


The forms reproduced here are used by the SEL at the Goddard 
Space Flight Center to collect data on development proj' 
ecta. The terms used in these forms are defined in Sec- 
tion B.2. 

B . I SAMPLE DATA COLLECTION FORMS AND INSTRUCTIONS 

This section contains sample data collection forms and 
instructions for their use. The instructions precede the 
forma. The following forms are included: 

1. General Project Summary (GPS) 

2. Resource Summary Form (RSF) 

3. Component Summary Form (CSF) 

4. Component Status Report (CSR) 

5. Run Analysis Form (RAF) 

6. Change Report Form (CRF) and Attitude Maintenance 
Change Report (ATM) 
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OF POOR QUALITY 


INSTRUaiONS FOR COMFLCTINC THE GENERAL 
PROJECT SUMMARY - FORM SSO>l 


Thii fonn it uMd to clauify th« projtct and will bt uitd h conjunclkin with th« other 
nportiiic form* to mMiure the eiUnuied v«nw actual d*v»|ot>meni profre«. It thoukl be 
fUled out by the project manaier at the befinnins of the piroject, at each major milenone, 
•ltd at the end. Numben and dates uaed at the initiation of the project are aaiumed to be 
ettimatedi Inicrmediate reports should chanie estimatas to actuals (if known) and update 
estiinatea. The flnal report should accurately describe the system developmeni life cycle. 

A. PROJECT DESCRIPTION 

Description. Give an overview of the project. 

Inputs. SpeciOcations and requiremenu (etc.) of project. Give the format of these. 
Requirements. How requirements arc establbhed and chanted. 

Products Developed. List all items developed for the project (e.g., operational system, 
testini system, simulator, etc.). 

Products Delivered. List all items required to be delivered (e.|.. source of the ope^ 
ationai lystem, object code of the operational system, design documents, etc.). 

B. RESOURCES 

Target Computer System. S> >em for which software was developed. 

Developmeni Computer System. System on which software was developed. 

Conatiainti. List any size or time constraints for the finished product. Do you aniicn 
pale any problems in meeting these constraints? 

Useful Items From Similar RroJecls: 

1. List previous projects, which will contribute varioua upsets to this project. 

2. For each project, give the percent of the cunent project it makes up in each 
of the 3 listed upsets. 

3. For MCh of the 3 listed aspects (specification, duign, code) check what level 
of modifications arc necesury. 

C. TIME 

Slut Date. First date of work, including design and modification of the specifications. 
End Dale. Delivery date. 

Estimated Lifetime. Estimate the operational life of the system. 

.Miaaion Date. Scheduled operation date of the system (write unknown if not known or 
undecided yet on any of theu daiu). Date project must be operational. 

ConfMence Level. Give the percent probability you think the end date is realistic. 

(e.g.. 100% means certain delivery on that date. 0% means no chance of delivery.) 
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D. COST 

Call. Total amount of mon«y th* projtci aotlt, incluUin* both contract anU m>houw 
coiti. 

Maximum AvaibbI*. Maximum amount avtilabla, indcptmiani of what MiimatcU com 

II. 

Confldanct Laval. Rate percent reliability in cost ettimatc. 

How Determined. At initiation how ii it eMimated, at compbtion how it it caiculated. 

Penonnel. Give the number of full time equivalent penoni required at inception of the 
project. I a of the way into the project, 2/3 of the way into the project, at the com* 
pie lion of the project. 

Total Perion Month!. Give the total number of montlu that full time equivalent per* 
loiiiiei (manaten, deiipnen. proframmen, keypunchen. editor*, lecretarici. etc. i are 
aitigned to clie project. Do not include all overhead items such as vacation and tick 
leave. 

Computer Time. Give the total number of hours on alt syMemi normalized to one 
machine le.n., the IBSI 360,75) and name the machine. 

& SIZE 

Size of the System. Include the total amount of machine space needed for alt in«truc* 
tions generated on the project plus tlie space for data, library routines i e.tf., FORTRAN 
I O package) and other code already available. Break down size into data space and 
instruction space. 

Confidence Level. Rate percent reliability in size estimates. 

Total Number of Source Statements. Give the number of FORTRAN, ALC, or any 
other lanfuage instructions generated specifically for this project. 

Structure of System. Give overall structure of system. 1s it a tingle load module, is it 
an overlay structure, or it it a set of independent programs? For overlay and separate . 
programs, give the number and average size of each. 

Dcrinc Your Concept of a Modub. Give the critena you arc using to divide the soft* 
ware into rnodubi 

Estimated Number of Modules. Include only the number of new modules to be written. 

Range in Module Size. Give the number of instructions in the minimum, maximum and 
average module and the language in which they are written at a reference. 

Number of Oiffercni I/O Formau Used. Give the number of diuinct external data sets 
that are required tbr the system including card reader, printer, graphics device, and 
temporarv tiles. 

F. COMPUTER ACCESS 

A librarian is a person who can be used to perform any of the clerical functions associ* 
jttfd with programming, including those given on the chart. Cicck the appropriate boxes 
for those persons who liavc access to the computer to perform the given functions. Give the 
percentage of time spent by each in batch and interactive acccu to the computer. 
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C. TECHNIQUES EMPLOYED 

For "Uvcl." specify to what level of detail in the nnisheU project the technique is used. 
(e.|., subroutine, module, segments of 1000 lines, top level, etc.) 

Spectficaiions 

Functional - Components are described as a set of functions, each component 
performing a certain actioa 

rtocrduml • Components are speeded in some algorithmic manner (e.g., using a 
PDU. 

English - Componsnu are specified using an English Language proM statement of 
the problem. 

Formal - Some other formal system is used to spedfy the components. 

Design and Development 

Top Down - The implementation of the system one level at a time, with the cuirent 
level and expansion of the yet to be defined subroutines at the previous higher level. 

Bottom Up - The implementation of the system starting with the lowest level rou* 
tines and proceeding one level at a time to the nigher level routines. 

• Iterative Enhancement - The implementation ‘tf successive implementations, each 

producing a usable subset of the fmat product until the entire system it fully 
developed. 

Hardest First - The implementation of the most difficult upects of the system Tint. 
Orher - Desenbe the strategy used if it it not a combination of any of the above. 
None Specified - No particular stntegy has been specified. 

Coding. The final encoding of the implementation in an executable programming 
language. 

Structured Code With Simulated Constructs > The language does net support ttruc> 
tured control structures (e.g.. FORTRAN*) but they are simulated with the existing 
structures; please state the structured control structures you are using (e.g., WHILE, 
CASE IF). 

Structured Control (instructs •* The language supports structured control struc* 
lures (e.g., a FORTRAN preprocessor) please list structures you arc using. 

Other Standard - Describe any other standard you arc using. 

None SpcciRed - No particular strategy has been specified. 

VaUdathm/Verifkaiion. Testing; execution of the system, via a set of test tutu 

Top Down • Stubs or dummy procedures arc written to handle the yet to be implc* 
mented aspects of the system and testing begins with the top level routines and 
proceeds as new levels are added to the system. 

Bottom Up - Check out of a module at a time using test drivers and starting ar :ite 
bottom level modules Tint. 
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Structvirc Omen - t'lmi firucture <jl proeram to deiermine leil Jau every 
tUiemeni of program cxeuuteti ai leait once). 

Specitlcation Driven • Ufinf ipecificationt of program to lictcnmne test data (e.|., 
all input output relationihipi hold for a wt of te«t data). 

Other > Deicnbe any other ttrategy you are ueinf. 

None Specifled - No tettinf itraieiy liaa been tpccifled. 

ValMatiun/Vcrincstion. Inipection: vuual e.vamination of the code or desi(n. 

Code Reodlni • Vitual Intpection of the code or detiyn by otiicr proyrainmen. 

Walk Tlvouiht - Fornul meetini teuioni for the review of code and detim by the 
varioui memben of the project, for technical rather than manafement purpoiei. 

Prooft - Fornul proofi of the deuin or code; pleate tpecify the technique* used, 
e.y., avomatic. predicate traiiiforim, functional, etc. 

None Specified - No inspection techniques have been tpectlled. 

Tliere is wme space given to permit the further e.splanation of any oi the tiratcfies that 
may be used. 

FORMAL NOTATIONS USED AT VARIOUS LEVELS \ND PHASES 

Give the phases 'e,|.. design, implementation, tettiny. etc.) and levels isubrouiine. 
module, segmenti of tOOO lines, top level, etc.) at which any type of formalism iflowchari. 
PDL etc. ) wilt be used in the development of the system. 

I. AUTOMATED TOOLS USED 

Name all automated tools used, including automated versions of the formalisms given 
above and compilers for the prugramminf Isnguages used, and at wtileh pliase and at what 
level they are used, Include any products that may be developed as part of this project 
le.g., simulator). 

J. ORGANIZATION 

Describe how the personnel arc subdivided with respect to responsibilittes into teams 
or groups, giving titles, brief job descrlptiom. the number of people satisfying ilui title and 
their names and organizational affiliations if known. 

K. STANDARDS 

last all standards used, whether they arc required or optional, and the title of the 
document desenbing the standard. 

L MILESTONES 

Give the phase at which management may cheek on progress of the development of the 
system le.g., speeiflcaiion. design, implementation of version I, etc.). State also the date at 
which It should take place (at completion of the project), how it is to be determined that the 
milestone was reached, who will be responsible for reviewing (he progress at that point and 
what the review procedure will be. Also give the resources used since (he last milestone. For 
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iU« of tyiitm tiv* iht currtnt ii» of ikt at that milntent. Each milattona haa 2 
oonfldancc Icvcb, on* for tima catimatac and one for raaourct cxpanditurca. For ctciinaicd 
future milaatona. tha flnt confidanea (aval for tha probability of raachini tha milaatona at 
that data. Tha tacond it for tha accuracy of tha ratourcaa ua^, For part milaitonaa. the 
flrat confidence taval ia normally 100% (actual data) while tha aecond it an ettimata on the 
acctiracy of the accouniini tyittm. 

M. DOCUMENTATION 

For each time of documentation developed, itatc tha type of documanution, ita purpoia, 
the date it thould be complcird, itt tiza and liii any tooit used in itt production. CAt the 
bcpinmni of tha project theta thould be citimatct, at the end of the project, they ihould be 
accurate fliuret.) 

N. PROOLEMS 

Give the three moat difOcult probleini you expect to encounter manafitif titii project, 
neaaa be at tpadfic at poiiibie. 

O. QUALITY ASSURANCE 

To what do you attribute your confidanea in tha comptatad lyttam. Be u tpKifle at 
potiible. 
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INITHUertONt POR COMPLITINO THI MtOUNCI SUMMARY 


Thu form knpt tfiek of fh# projKi com on • wMklv Miii, ft should bo fillod out by tht pro|Kt 'tioroflir ovorv wot* of lh» 
groitet durition. 

PROJtCT. Givo proioei nomo. 

OATt. Utt dost form tusnod m. 

■m 

NAMi. Nomo of oroiKt monitor, 

WCIK OP. U.st ditt of iieh lueensivo P'ldiy. 

MANPOWIR. Uit 1(1 poMorrrtol on tht proiiet on itporito linti. Glut tht numbtr of hours tKn iptni thot wttk on tht pfojtet. 

% OP MANAOIMINT. Add tht % of timt this ptnon iptni mini«(n( tht proitot durlnj this rtponint ptrlod. A now form should bi 
ustd if this % chintM. 

COMPUTIR USAQI. Lilt III miehinti ustd on tht proitet. Por tich mtchint flivt tht numbtf of runt during tich im ?k ind tht 
imouni of computtr timt ustd. 

OTHIR. Lilt iny other ehirgti to tht proitet. 
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INtTNUCTIONt ^OR COM^blTINO TNI COMRONINT SUMMARY 


Thii form u Mtd lo irMp tricti of tht compontmt of • tvntm. A comoononi >t • «iko of int iviltm idoniifitd bv nim« or 
common function to «n tniry in t uit cbwi or biUMint Oi*ft*<b for tbt ivtttm it *ny point m timt, or « ihirod itciion of 0*i« tuch 
M « COMMON Moctil. Wiin ifM intorm«iion on tbii form come«n«d wttft tht mformtfion on tro Compontnt Siiiui Raport, tn* tifuc- 
turo tnO tiiiui of tbt >v«»m and ni dt»«opmtnt can bo moniiorod. 

fbii form mouW bo filtad out tor tKh compontnt it tftt timt (tut tbt compononi ii dtfintd, it tht iimi it it compltiid. tnd at 
tny poini m timt Mhtn t mt|or modifieition to tht compontnt n mtdt. U thouhl bt t:Htd out by tht ptrton rtiporttibit for tht com- 
pontni 

RROdlCT. Qiwi prottct ntmt. 

OATS, Oiyt dtit form ftfltd out, 

NAMI OS COMSONINT Guta ntmt (up M • chirtettitf bv which tho componani will bt rtbnrtd to m oihtr formt, 

■RIIS OISCRISTION. Sittt function of compontm. 

TVS! OF SOFTYtARI. Chtck all citinfictiioni tMi tppty All common bfocki trt MPtrtit compontnti. 

STATUS OF COMFONINT. Chtch whtthtf thit it t ntw compontnt, whtihtr it it t compontnt unOtr dtvtiopmtnt It 8<, t privioui 
compontnt tummtry hti tirttoy bttn luomiittdl, or whtihtr tht compontnt it now compitit 

A. COOS SFICIFfCATIONS. Gmt tht form of dttipn for Iftit eomponant, and toll to tditt Imtl of dtttil tht tpteificatiant trt (t«tn. 

Funttltml-Compantntt trt dticrfbtd tt t itt of function!, tKh compontnt ptrformin^ t ctrttin action. 

Frocadurtl-Componanit trt tptcifitd in tomt tiforiihmic mtnntr It.g., utinf i FOU. 

■niHih-Compontnti art ipKifitd utinp tn Inftith Ltn|uttt orett itttintnt of tht problim. 

Formtf-Somt othtr formal lytttm it uttd to tptcify tht compontnn. 

Rtittivt to tht nnt dt«tlopin« tht compontnt. rate tht prKitlon of tht toteifittiiont. Vary prKitt mttnt that no additional tntlytit 
on tht problem n n tod t d. prKitt mtini that only atty or trivial idtti htvo to bt dtvtioptd, and imprteiit mttnt that much work mil 
rtmtini in dtvttoptnf thit compontnt and lit bitw tmictura. 

«. INTIRFACIS 

Givt lilt rtIttivt potition of thit compontnt m tht lyntm. Giya tht numbtr and Hit tht ntmM of all compontnti that call thit 
compontnt, and art eailtd bv thit compontnt. Alio, «wt tht nimai of my eompontna or othtr ittmi thit compontnt thirtt with 
othtr compontnn It.f., COMMON Mpcki, tattmtl dtitl. Tht compontiui dirteilv dtMtndtd from thti compontnt rtftrt to tht trtt 
chan cr tht lyittm. It tht initrfKti trt not ytt eompitit, chock "Not Fully Sptclfitd". 

C FROGRAMMINQ LANGUAOIS 

Ult Itnfutftt lor ttttmbiv Imfuiptil to bo uitd to Impicmtnl thit oomponant. If mprt thtn ont, Hit parctnttttt of tich |ln 
lint! of lourct eodtl. If thtra art tny conitratmi on tht oomponant lt.|.> Htt, tiMuilen timtl Hit thtm, Alto (WO tiiimttid tut of 
finithtd eomponant in ttrmi of teurct nattmantt, Ittiimaia ittt with commtnii and wlihout commtniil and rttulilni maenmt Itn- 
duapH (Includins dau arcat, but not COMMON btockif. 

Utalul llama From Simtlw Rroftcti 

I Litt ortvioui eomponana and proiactt which comributt varioui aiptett to thia cemeonani. 

2. For tKh tuch componani, givt IN oarctnt of iKh of iN thrat Htiid aiptett it maktt up It.S'. a compontnt may N 50% of 
dautn lut oniy 2S% of c da dua to changad intaifactt. ate.). 

X For IKh of tht thrat Hit; tiptcti, chMk what lavai of modlfleaiiont art nacaaaarv. 
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0 . COMPLIXITY 

Nim vpur UJli«f In tnt comolMiiv nf tn« imoltfrwnutian Alio MproiMuH llw numocr (by SI ot Miignr int ivpi iiit«n<«mi 
(input itianitno «rt meluMbl, «nd control itiMnana (thoM t ut (iHi in# flow of cdntrol #.9'. 1^ . CALL QOTOI Tht sum of th#M 
two mty not b# 100S (o.f., CONTINUf , OIMCNSION ino RIAL ictMfnonti wilt not bo couniodl. I/O «n0 dtclorotloni iheuid b# 
liittd M ointr. 

1. NIMUNCii TO IMALIMINT 

bar #och of th# thfto luttd pnim (Ottign, Codo, TtttI, Mtimitt comouttr run*, timo n#*0#d, Hour* to impi#m#nt. ind titi- 
matod compl#t>on dot*. If not known, or no Mtimot* un b* givtn, moIm "unknown". 

b. OmOIN Ob COMbONSNT 

If tfiii componont ii indttxndont of *ny otfior eomponont of tfw lyittm lo.f., ii t low lovtl eomeonont wfileh i* doitf nod f irit, or 
li th* root noo* of in* ir*o chin) than elioek yoi, othorwii* cn*ch no. * 

If no ltch*ck*d, thon tipltin why th* componont wm *d4td..4U*u*llv only on* r«*ien will b* chfckod, although mor* may b* 
chackad, if approprt*t*l. 

A lowar tavai alaboratlon of a highw laval eomponant mtani that an akiiting eempontnt wat anpandtd to indud# n#w eomp» 
n*nn l*.g., •ipanding tr#* chart). Uit ih* high#r l#v#l compontni tim«. 

Addtd M a drly«r or Intorfa** moan* that • calling program wh added to call aaiailng compononti. Ur that* cailtd compontnti. 
A ri d «iig n of an oaiating eomponant moan* that now capobilliiai w*r* added to an already oaining oomponwR. Writ* ita name. 
AranamOigof iinoldoraomoonont. Qiy* the old nama. 

A rognMpMg of Miaiing msi*ri*l m**nt that aovoral eempononn warn mdoalfnad with a now eomoonont l••ulllng from thla i*> 
dadgn. Sly* dt* old eomponant nanwa 

Typo of addMam. Why waa dila eomponant added to dt* ayaiom at thla dm*? Chada th* approprlaia leaaon. (Normally, only 
on* ahould b* chockad, aldiougfi 'nor* can b* if tpproprtaia.) 

0. ADDITIONAL COMMINTS. Add arty odMr eommana dial will help aaplain dw purpota, dMign, and eompioaiiy of mil com. 
pononL 

H. bf RtON MSbONSItLi. Indud* name of parton reiponiibl* for implamanting eemponont 

1. biftSON bILLINO OUT bOMM. Diva name of parton filling out form. Thii nomtally la th* lam* nama a* in H, 
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COM^NENT SUMMARY 


»««Q-igeT 

NAMI OP COMPONENT. 
■flIEP OiSCRlPTION 


DATE 

CREATION DATE. 


STATUS OP COMPONENT NEW___ 
TYPE OP SOPTWARB (ChMk Alt That Ao«lv) 
__l/0 ProoauMi 

.^AliAfiihmic 

‘"fi* Control 

A. CODE SPECIPICATIONS (ChMk All That Apply) 


UNDER OEVEL. 


COMPLETED. 

.Syittm Raltti4 
.DATA/COMMON Block 
.Other 


LEVEL OP DETAIL 


PORM OP DESIGN 


Camponant Subaemppnant 


Functional 


rectoural 


' Formal 


OtPtf t 

Prtcliion of Coda Soaeificaiian Vary P 


6 interfaces 

Number Compontnti 
Mumbtr Calling Thit r«winnmnt 
Nuinbar Sharad 

Numbar of Componanta Olractly Oaioandod from Thit Compenant. 


c. procramminq lanouaces 

Ltnguagai Uiad and ParoaniHn..._ 
constraint problem EXPEaEO; 




.Net Fully Spaeiflao . 


.Not Fully Soaclfiad . 


.Not Fully Spaeiflao ..... 


.Not Fully Soaofiad . 




Conitramt 

Praiant 


Cdfflponant Mmb 
C onttraint 


Memory Spaea 


Eiacuiion Tima 


thar I 


Slaa: Sourca Statamanti (Including Commantil 

Source Statimanit (Not Including Commami) 
Uaaful luma From Similar Proiacti 



Madiino Byttt. 
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0 COMTliXITV 

Com 0 i««ity of ^unction ■«»“ 

Aitiinmoni «»«««"» Control SiiMmonii. 


■i Othtr SiiHrriiiMt i« Soto C«ei. *'0) 


I. MSOUHCiS TO IM^LCMCNT 


Effort (hri) 


Ell. Ccmoloiion Cut 



F It tnit comoononi inOoptnOoni of ttM OMiitinf 

If Ho. dMcribt rtiailen of thit compontm to tho taiitini lyittm: 

— 41 4 lowtr lovol •Itboration of ftlfhar lavtl eomponanti 

I II I drivar or imarfKa for aaiitino compenomi 

« rMaii«n (to add now caMdility) of aaiitinf eomponanti 
« rtnaminf of aaittin| componant 
__rairouoing of Miitmo matanal from lavaral eomponanti 


Tvpa of Addition; 

wwir eorraetlon 

___plannid anhaneamant 
___implamantation of roouirimanti enanga 
____imgrovamant of elarity. maintalnaOilitv, or doeumantatlon 
__otfiar liaplain balowt 


. Improvamant of ujir larvfea 
.utility for davaloomant oorpowi only 
.oetimliation of tima/ioKi/aceurKv 
.adaptation to anvironmant cltanga 



H. PERSON AESPONSISLE POR IMPLEMENTING COMPONENT. 

I. PERSON PILLING OUT enOM 
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u mOH QUA! nv 


iNimucTiONt ran eoM^iiTiiM thi commnint itatm mport 

Th4i form it w to uito to MCuniMv tooo VKk of tto towtoomom of oMh oornoonmi in tto iviitm. A Cempontni Sumnufy 
Aopon itouli fRitt for toto componom miniionori, Tto form ii to to tvrno4 in M tht tn« of ttch wotk. Mom* fitl out (ilhor Mly 
or enct MCh mtk. If tolly, tnm • (iron Mmoonini m*y to liitto Mvorii timof torin« ihi count of i witk. ker ttch eompontnt 
lilt tht numOir of noun iptni on ncn of tfii liittd tctivitiM. Thii form ikouM to filltd out by ptnoni workmt on tnt preitet. 

MOJICT. Ntmt of tnt proiMt. 

OROQNAMMfR, Ntmt Of profnmmtr. 

OATI. Oitt rtoon turntd in. Uiutily tnt Out of t RriOty- 

eOMRONINT. Ntmt of componint. litntr i port of tnt lyittm itructurt for wnieh thtrt it • eompontnt lummiry form, or ont of 
tht followini; 

JCL. Otvtioein«eommindltn|ut|tln«iuctlam. 

Onrliy. Otvtlooini tyittm evtrtiy itructurt. 

Umi OuMt. Uitr'i Quito Ooeumtntnion. 

tyiam Datripiion. Syittm Ocicriptlon Documtnution, 

MSIQN 

f 

Crtitt. Writmo of t component 0«ifn< 

» 

RiiO. Rtidino (by ptr) of d«i(n to look for trrori. (t.f., pttr rtvirwl 

■ 

ktrmil ftwitw. Rormti mtttingof iwtrii InOlvidutii for purpoit of tROUining Onign. Alio include time lotnt in ortotring for 
review. All thou ttttndlng riviewihould Hit eompontnu OiicutMd in thtir oAn Component Statui Raport for tnat weak. 

COOiyOIVCLOAMINT 

Cede. Writing tRteutablt initructiom and dark enaeking program. 

Read. Coda reading by pear. SlmHir to Otaign Read above. 

Rormai Review. Review of coded componena Similar to Otaign Review above. 

TtSTINQ 

Unit. Unitteating. Tat run witn teat data on tingle module. 

Inta» Integration tnting of aevtraleomponenta. 

Review. Review of tMting atatut. 

OTHIR. Any other aapeet rilattd to a component of the proieet not already covered other than Otaign. Coda Oavtloomant. Tnt 
(e.g.. Oocumentation of a ipacific eomoonentl. Liat type of Ktivity, and houn loent on that activity. A tat of aetivitin hai been 
liated for wnich time may be cnanjed to the ovaratl project; 

Travel. Time ipent on official travel related to tnia project, (including tripi to and from GSFC). 

Forma. Time ipent on filling out reporting forme. 

Mectinga. Time ipent in mHtingi wnich are not dealgn or code review mntingi. 

Training. Training activltiea identified for ptajict. 

Ace Teat Aceeptana Tnting activitiet 
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ORIGINAL PAGE fS 
>• POOR QUALITY 


COMTONENT STATUS nSI»ORT 


MOJKT 

M00NAMMI>< 


OAU 











ORIGINAL PAGE TS 
OF POOR QUALITY 


INITNUCnONI roil COMHITINO THI COMrUTIR mOQIIAM RUN ANAiytll rORM 

Thii form will tw uMd to momior ino octivnioi let whicft tht comogiir n uu« m tho oowrto or • pioioct ilfo evoit. An tniry tnouU 
bo mobt lor tun oomputft run^mclMlino ill utiviiiH porformcP whon tno oomoutor n uMb in in intmaivi mobt 

RROORAMMIR. Wriii down nimo of porun pripuinf Mmpuw rum. Thii miy not ntOMUrily bo IM pirwn runninf llw proirim 
li.o., Iibtiriinl. 

M9JICT. Wfiii down oroiMt nimi, Um i diNtrtnt form lor lun orown. 

OOMPUTIR. indicjii thi micnini on wincn iniM runt wro modi ii.d., S/SM. POP*n. SSI 
DATI. Oitl form turnid n. 

JOR 10. Idimilicilion d> |00 

RUN DATI. Oin 'un lubmitttd m formit MM-00 imemndiyl. 

INTIRACTIVI. Plooi in X il ino run wii wfemmib from in innriciwt itrminil. 

RUN PURPOtl PiKO m X m HI bom inii duvibo ihii run. 

Umi Tut A pur COM of tho run ii to iitt ono or moro componmti without tho rut el tni lyitim boinf csnfifurod mio the lud 
meOulo. A run which um i ‘tut drl«or' wouW l|ll into thii ciliforv, 

Syttont Tut Thii run wtouiii • iMd modulo whien oontiim ill ol tho eurrmtly iviiUpli tyitom m orOir to ttit om or men 
oomponinti in i lull tvMom oenlifurition. 

•inchmitli Tut. Thi» i| i nuriilicition lypi rua A run tnit hii luccuilully nteutid in tho put n new rtrun to nrily thit 
cortlin uoibilitiM itill tint. 

MointimmiiUtiiitv. A ourpou ol tnit run <i to perform i 'librirytypo' function. Ciiniein m rum tnii uoditi wuru. eriitt 
bichupt. dtlttt comenH/coov dill tut. 

ComprIi/AiHmMyrLinh. A purpoii ol Ihi run it to chicX lor trreri in thi eomptli. iiiomoly ino.'or link met. A run which n- 
eludu om or mere ol tnoto mot iimpiv it i pnnquiiiii to i lyiiim iioeuiion would net fill into thii atoiery. 

Oobuf Run. '^hit run wu lubmiitid n order to in/Mli«iti • known mat, 

O^hor. THit run tut i puroow which dou not fill into om ol tm other eituionti. EximoiM in rum wriich lectit othtr ivtitmt 
■n order to iid m the ditipn. diviioomint ind/or t«tin« ol the erenei undu nudy. 

COMPONENTS OP INTEREST. L.ii HI comoontnti imoortini to thit run (i.p., eompommi Diin) tutid. eemoiitd eooiid lie i 
PiRST RUN. Pliei in X hri if tnit ■» thi frit timi »ny ol the iiitid eompontnti nut bun oroumd by tni eomouitr lor tnt our- 
poit ol run iptcifitd. 

MEETS OSdECTIVEl Thu 1 1 tubitetivo uituition ol wnumr tm run tiinfitd your obitctivu. Rum thit ttrminiit m trrori miv ot 
utiilictorv if the oDioctivi wu to locitt trrori or to tut for corroetmti; rum tnit itrmimii normilly miy bt umitiilietory if tht pur- 
oott wit IP loam in error known to be prumi. Thus thit quution it indipmdont of whuhtr the proirim oontiintd iny ir rort pi not. 

RUN RESULTl Chick tho bei thit but OfioritMt the ruulii of thii run. Normolly only one boi ii chtcktd. Hthoutn mon mm one 
miy bo chKhid if oeproemio. 

deed Run, Proyim nn to iirmimiion with no known irrori. 
loMp Error, Error m vtiimt prognm dick. 

Submit Error. Dock lubmitM incorrectly, ntourtu unwiiliblo, keypunch irrer. or gcnuil tubmiuion error. 

JCU Error. JCL iiitimim moornct. UCL cirdt mittvpid ihould bo limd undu lubmit urort.) 

ninw suup Error. Such it imufliciont ipico or time ipoeiliod for job nop. Thit ihould net bo ciuHd by profrim uror, 

Muhim Error. Errori ouiiidt of tho oonirol el tho prosrammu. 

Hudwm Error. Machim miifunction. 

Soltwirt Error. Syiltm eriin or tytttm prouim uror (a.g,, uror m FORTRAN sompilul. 

Neu«m Error. Error eiuMO by tno tubmiiitd preuun. 

Compile Error. Tho tourco prognm eoniiini m uror which ii found by the eompilu or ittomeiu. 

Link Error. Tho loodu or linkiga tdiior findi in uror. 

Ekteutt Error. Sytttm irror mtuagoi ua gonuitid during tht tkteuiion mo, potiibiy muting m ibmd. 

Utu Ctnuiiid Error. Tht proqrim tumimtti m a progrimmu ginuittd error mttugt which n not i tytttm ti’ror. 

Pm to Comoliiion. Tm program tumimttd with no uror mitugi; howivu, the ruultt uo moornct iignifving that tntn >t 
wmttning wrong with tm pregrim. 

COMMENTl If you biliut tmt your mtwut to tntti ouittiontdo net idfduitiiv ehirictuiti thit run, you may aoa mv jdditionii 
oommontt tnii you with. Alto uto thit toici to indieiti if tho run wu loit before you hid i ehmci to ualuiti ruultt. 
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ORIGINAL PAGE IS 
OP POOR QUALITY 


MSTNUCTIONt fOR CONIKITIMO THI CMAlMI NIKIIT POWN 


TMtftifiiMutMlMkM»trMfc«(iliilM>ifiiniGtwafvtNin. AiNnititinYilMrMlonMtfMMin.tfwumwMIiGn.arMG* 
RlRWiMtriil^fVfwm. TtMinitMtfMMnffiNMMof 

On* tNtnf* r*o«ft fam itauM fe* nn*0 mi f*p mh *h*nf*, Whtr* w««p*I tMn*H tn matt limuMafMMNv far «if f*f*nt rat* 
MM a MMrai* Rkri hmuM b* aawRia a a * tar aaan nmn, 

NUMMR. A uniMa iGamiflar Mr farm par Gay aantMinfaf )nlnaia taHanmG ay a l a auanM nwmtar. Th* miilAi iNmIG a* taaw af 
laa parMA ftllinf mi in* tarm. ia* MauauM numaar iiimW a* a aatUlM imafar maiaatini in* mtmaar a( tarmt nilaa am m far Gyr- 
iflGin*^. Numaar OMWOI rnGtaai** wa Ww tarm aMn* Gay WHaG am ay OMW. OMWOa >* Wa laa an G tarm inai Gay , at*. 

MOilCTNAMI. Ttia nama at iN GaMlaawani ara | aai. 

CURRINTOATI. INGaMariMiMahanimiry N (immaG*ania*farm,*«anifin*tarml*n#ta*m 0 <*i*GantnaiG*y. 

nenoN a^ointipication 

RIAMN. laplaiAwnyGM*nan|aNaainGm*Ga. 

eiKNIPTION. Oaiaria* Gw anam* Gwi la aaiiw m*G*. ThW GwuM naa a* an Gw y*rl*aw nama ar ait Wmt, am GwulG a* MiWl> 
alamiv iGitraat la inai in* fuMtian af Gw *na«w*G aaGa aan aa GaiarminaG, a.%., "Gw InMi aiiftar wa* ataaraG," rawar man "array 
auN wa M M lara." 

IPPICT, Whai aampanana (ar Gaauma n ii) art anarwaG? U«i Gw namaa a» *M aampanan n awG G Mu ma nt i maGHlaG ti M*t a* tna 
cn*iw*> inaluGlnf vartlan numaari. 

IPPORT: iwnai aGGlHanai cam par amt lar Gatumanm war* aaaminaG in Gatarmmtpf wnai ^lani* wm n**G*G7 tn all camaoMnn 
ana Gecumanii that war* aacmtrwG, Gut war* not actually cnanfiG, in G*clGln« wn*i enarif* to maha, naw la man* ti, atiG wn*r* to 
man* It. T>iii lilt GmuIG net ovariaa witn Gw IlM of aampanami *nG Gaeunwnti actuaiiv enanfOG. 

• • 

OATIS OP CHANOI. Naaa far cnana* GaiarminaG an. Qlr* Gw Gaw on whicn n waa firit raalitaG mat a enani* wm nacGaG. 

Oiant* itartaG an. OlMGwGataonwniantnaafwniaawaiartaG. 

Whai waa Gw affort In panamUffw raauGaG M unGantanGanG Imalamam ilwananf*7 

Oin Gw baai acallaai* aitlmata af Gw latal lima iwaGaG la u n Ga man G wfwt alwni* haG ta a* maG* anG haw to maka it, induG- 
in| Gw I m aw m antation tl.na. ThiiGtoulGIncluMGwGmaafallparMMinvalvaGinmakiniinachanf*. AaanaaampW, If twaaaaai* 
aaah workaG • houn an Gw ahanfi. gw nwm markaG "an* Gay ta 3 Gaya" ihMiG a* afwckaG. 

nCTION f-TVPf OP CHANOI 

Qiack tn* an* kaa Gwi ban Gmariaai Gw chan«*. If non* af Gw ehanf* GaacrlotloM laam ta fit, ciwek otnar anG alv* a GauilaG 
Gaierloilon af Gw cfwnt* In Sactian I. If mmtG af tN Gaacriotiana laam a^ly aaoroorlata, mar* than on* boa may b* clwekaG. 

Irror Carraailan. A ehanf* maGa to eorraa an arrar in praviau* wark. If Gila baa ii clwckaG Sactlonc C anG 0 af Gt* chanpa rteart 
form GwuM b* comoWiaG. 

PlannoG Inhanoamant. Tfw inwftien of a boGy of aoG* Inta a arofram nub that wm Initially craataG at a Gummy for taatini purpeut. 
or aGGlny caMbtiity to an alraaGy aaittirw compoiwni aa part of a piannaG incranwntal davaiopmant. 

imptamamaiMn of RaGUiramanai Chani*. Aliarinf Gw lyaiam to eontarm to a ehanf* in raouiramanii impowG by tn* eustemar. 

Impraranwni af Clarity, M al n talnaaWty. ar Oaaamantaiian. Chanfoa mao* to improtw ooG* qualitv, luch aa improvinf inGantaiion of 
eoG*. rataouaneinf labaii for raaGabiltiy, aGdinf or upGatinf Gocumantatlon or corrMiinf iltarary arrora In it, luppraiainf raounoam 
information or raplaemf muiilplywccuGlnf MCtiont of eoG* with proeaGur* cGU. Corraetlona of violationi of proframmmf itanoarGi, 
anG Gciifn improvanwnia that GioulG n«w been yiiibl* in tn* functional toaelficationi of eomponanti of Gw rvittm ar* to be traatco 
at trror eorraniOM. Oocumanttiion uoGatti maG* concomitantly with a ehanf* inoulG b* traatao aa a pan of tnai enanf* anG eiatn> 
fi*G wiGi ttw primacy caut* of Gw ehanfe. 

Improcamam of Uaar SawWat. Purinf ayiiam davaleemtni, inGIvIGuG proframmera may find mat with vary Httl* extra vmrk tnev can 
proriGt tn* uaar with tOGitionai facilitiaa on too of in* funet'onG refuirtmanti of in* lyitam. Suen chanfea are citiieG ta .moroxe- 
mama to uaar aarvieaa. 
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ORIGINAL PAGE fST 
OF POOR QUALITY 


ti— w n ^ Oi m wii d OfM Cart*. OufltM mMt w ih« irafrim «mi taMflaiHv M travMa infamiMNNt inf tn« im ntm m 

utM •fran «N to 

OaHatoa T I aia/ tai ai/OM M ftta. Aaaaito)iatiaAiMia«aUH4toKiMHM«*<af ttoarav«mtoMMmamatiraaiai«wrtauatinMMu< 
tian tknt ar mamary rtaummami, ar m afeuin *MutM af tntm mmartcil iMUf mv to tuntn| ito Hfa«iilMnt «Mto «a ito laiatfla 

AtoamiaN to latoaiMMM CtoNto. Tha'*toiina«v''af»wfnNNmwmlitoftntota)nalMl«iuMttoMaraf>finiwtoMtoM«at> 
nwm ma mamtafWMt ti Itwif maatiana n am a^ tna wfttMrt IMafiWfv aratact A atwifa whaM <«um it« autitto 

ttHi aaunamr in maanM w to aaarMini lytiam, (amaUar. ar fwawara eftania^ '• 'afaraa# h tonranmanuily aauiaa. 

Wai mara iitto aM aamaanam aMatiaa to tha alttofi^ A aawaana m n aafinaa la to airacitv irwaiMa m a ananya if it aamiira 
luaraattnai tfiai ira ahanyaa wa it aamatni na tutoamaancnti aantwniny ttoM waravunai Chack yai if tita ananyt airtciiv mwwM 
mara tfito arta a aw aana n i af tha tyatarw, na atfiarwua. Itway tottoawaatataatonyataanaiutoaatina/aamaawtotimHfaaMfa 
«ma futura aa i utt m ant in aaiar aamaanama (tfiaia aamaantoti may nat avan fwa toan aaaaa vat, or tfiair aaaatitiart may to aait* 
aanaa). In wah aatai, tto affaott af tfia afiaay t irwaiaa mara tfian ar>a aamaana m aato thaayh attfy arta maaM i t wai nataa ai tfttoyia 
to t«M farm. 


•ICTIQN e-TVra Of IllllOfI 

Ctoah tto ana too that ton toiaritoi tto irrar. ltnanaafitoarrartoMriatianataamtaflt,atotkattoranf yMaafataitaaam 
MrifUan af tto atrar in lactian I. 

WaaMwamanai Inoorraai at MMnttr at twy. faywirtmtoti may to inaarraat linaantittam ar amiiyuawl, ar ttoir maaniny may to mii< 
iniiraraiai. in aittor taw, an arrar af tMt tyaa. if untotaaiaif aarty, may pratoyaia tnrouyfi OHiyn an# inta tato. itir* unaataaia# 
uniii aaetautoa taitiny (ar mamtananaal, arrart raauftmy (ram inaarraat or mtaintararataf raauirtmtntt itouftf to (Hit in tto r» 
OMiramtoit arrar aatayarv 

tonattanaf taaottoatom Inaarraat ar Miiinttrarataf, funatianal laaaifieatiana art takan ta to a waaiflaaiion af a camaantot m a tat 
of funetiam dafinmy ma autaut for any mout. Similar to rtauiramanit, taaalfiaatienf may to aittor inaarraat or muimararatto. ir- 
roM in tto ipacifleatioflt that oatur at a raiult of mitunatritanfinyi of raauiramanti art elaiiifiaf tl miiinttrprtttil raouirtmtnn tirer* 
ma not inaarraat laatifiaationt. Soaaiflattion arrart that rttuli from mitunatrtttnainya tmony tnoit.writiny tto taaeifieatiant art 
eiMiifiaO at maorrtat laaaiflaationt. brort m aaOa or attiyn or Ooeumanti raiultlny from inaarraat or miiinttrartta# tpaaiflettioni 
tnouia to alaMifiaO in tto laatifiaatiarN arrar atityary. 

Otiiyn Irrat IntaMny Sayaral Camaa n t n ta. A Oaiifn Otaitlon it a atoict of amaniiatian af a oamaontnt inta tutaamaanantt, in- 
eiuOiny tto tataifiattian af ii.i» iniarftatt tmany tto tuMomaanantt. A Oatiyn arrar it a Oatiyn daaitian that ratuitt m ant of tto fol- 
iowiny; 

a intarfacat that aomtin intufflaiant, unnaaattary. or raOunOtnt information; 

a a lat af lutoomaananB ttot to not tatiafy tto taaoifitttlant of tto aamaanant li.a., ana or mr> t of tto tutoompanantt to 
not haao tto a paWIttiat natOaO ta latlafv tto uta ImanOao far tfw o am aanantl. 

Nllt tlittt a Oaiifn arrar may raattit (ram inaorraat or mitinttroroitO raauirtmantt ar i#aii(laati;na. In tuah catat, tto arror 
mouiO not to eitair^ at a Oatiyn arrar, but aa a rofuirafflaiiti or taaaiflattian arrer. 

Irrar in tto Oatty n or Impl t mantattan af a Sinylo Ca m to n tm. Moat timala, localitad proyrtmmmy mittaktt fail into thli ettayory. It 
cyrftarH tkfia eaiaa wtora tto oryanintion af tto tyttam inw lomoonann tno tnair in^aati it eerrttt. Out a omieular eompenant 
Oytf aat batora aeoorOiny to itt intanOaO uia (i-a., Ooaa not eorratoanO to in laaeificaiianl. Tbit moi ooaur bacauM tto atyoritton 
maO m Oaiiyninf tto aomaona m it inaarraat, or b aeama tto imaiamamatian af tto aiyoritivn it inearraci. if tto alyoiitnm nat a writ- 
tan ipaatfieatian arier » coto yanaraiian, anO tto laaaificatian it incerract or mltmtararataO, tto arror it nat elatuf iaO u a Oatiyn or 
imaiimantiiian trror, but aa a taaeifleatian arror. If tto arronaout atyoriilun toa no wrtnan iaaof'«atian, or if tto imaiamanution of 
tto atyeritiim toa arrart nat annbutabla to any ottor eatayory, titan tto arror it clauif iaO aa an arror in tto Oniyn or imaiamantation 
of a iinyia eomaonam. 

Mlw i nOartt i nOito af iatarnal Inabanmant Snaaat Lanyuoya. Ctoak thia boa if tha arror raiultaO from mitukan aaiumotiont atout 
ina torOwara or loftwara anvMonmont in wfliefi tto proyram oparaiti li.a., that toftwara outiiOa tto "bounOary" of tha erojaet-tat 
"aOapution to anvironmant etonya” in Station II. InaluOaf hara ara miiiakan auumpciont aMut tow tna aearatiny tyttam workt, 
loout tow tto harowara it eontroilaO, aboot rttpenta af itoipharalt to varioui MmmanOa, about tto oparaiion of tha llbrvv tyttam, 
tbout tha intarraea to loaeial oiipiav hffOwsrs sr tsfttora, ate. 

error in Uta of breyramminy tanynayafCompilar. irrort In tto uta of the lanyuaya/oomaiiar ara ttota arrort that ratuit from loma 
mitunoarttanoiny of how tna eompiiar workt, now tto lanyuaya proviOaO run-tima tuooon tyttam oaaratat. or toma mnunoaritanoiny 
of eanieutar lanyuaya (Hturat. Net mcluOad in thii eatayory ara elarieal arrort (a.y., typoii ttot iaaO to compilation rrori. 
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ORIGINAL PAGu 
OF POOR QUAUi V 


OwiMl iim, Omul m»n m t*WH mut thM etcur m tM m«Mnwtt irtnMMwn «t tn turn lf*m cik farmti i* wwtMf (tj.. ont 
KWM w tnmtm), m fr»m »fw tumm m nwtwr um>t tfiNH M wM. N» imwmf mim u wuMt€ vmMtm n m- 

POH OmOM ON IMNilMINTATION INNONS ONLY 

TIui Mi*«n iImuM to MHto Mt •«My i( tto (rrtf wm • toM|n mm, tntoMnt %umH ummtmu, or if ii wn an trror m tnt (to 
Hfn or loio d woo w iow of • im(|Io oow o onont Irrort ttoi ooiur mi ito toii|n of • iviwK, Mtovnom, mi of oomoorwiii, or Miiit 
oomoonom, or hi ttoimoiamomtttoiiof owioiauffiiMnom, mov toaoMforxto xi*"o*f momovi. tutor itorowoi wiorror mtto 
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B.2 SEL GLOSSARY OF TERMS USED WITH DATA COLLECTION FORMS 


This section defines the terms used in the software engi- 
neering data collection forms reproduced in Section B.l. A 
more extensive glossary (based substantially on this one) is 
found in Reference 9. 


assignment 

statements 


attitude/orbit 


attribute list 


automated 

tools 


baseline 

diagram 


batch 


All statements that change the value of a 
variable as their main purpose (e.g.r as- 
signment or READ statements, but the as- 
signment of the DO loop variable in a DO 
statement should not be included) . 

Any component that is directly related to 
either the attitude determination (or con- 
trol) task or to the orbit determination 
(or control) task falls into this cate- 
gory. This should include full systems in 
general (such as GTDS or ISEB-B Attitude) 
as well as specific modules such as Deter- 
ministic Attitude or DCCONEJ» 

A compiler-generated list of the identi- 
fiers used by a program that describes the 
characteristics of those identifiers and 
shows the source statements where they are 
first defined (or first used) and, for 
variables, their (relative) storage loca- 
tions. 

Any programs whose purpose is to aid in 
software development (e.g., compiler, text 
editor, or dump or trace facility). This 
includes compilers but not standard opera- 
ting system software (e.g., linkage edi- 
tor) . 

A structured chart listing all components 
in a system in which a connection from a 
higher component to a lower one indicates 
that the higher component calls the lower 
one. 

Use of a computer in which the entire job 
is read into the machine before the proc- 
essing begins and in which there is no 
provision for interaction with the sub- 
mitter during execution of the job. (In- 
teractive usage is always via a terminal; 
batch usage may be via a terminal or a 
card deck.) 
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bottom-up 


business/ 

financial 


change 


clerical 

code reading 

command/ 

control 

complexity 


component 


The design (or implementation) of the sys- 
tem starting with the lowest level rou- 
tines and proceeding to the higher level 
routines that use the lower levels. 

The second of the four major categories ap 
plies to components related to some ac- 
counting task, financial data formatting, 
business data retrieval or reporting, or 
pobslbly personnel data management. Very 
few of the components being studied will 
fall into this class. 

A modification to design, code, or docu- 
mentation. A change might be made to 
correct an error, to improve system per- 
formance, to add capability, to improve 
appearance, or to implement a requirements 
change, for example. 

The process of copying an item from one 
format to another or from one medium to 
another, which involves no interpretation 
or semantic translation. 

Visual inspection of the source code by 
persons other than the Creator of the code 

This class of components includes those 
used either to generate vehicle commands 
or to transmit these commands fioro the 
control center. 

Measures the difficulty of implementing a 
component, independent of the Imple- 
menter's experience. Easy (or simple) 
means that any good programmer can write 
down the correct code with little thought. 
Hard (or complex) means that much thought 
is involved in the design. (Compare this 
with "precise”; e^g., easy and imprecise 
may mean a vague specification, but once 
the approach is decided upon, the code is 
easy to write. ) 

A piece of the system identified by name 
or common function (e.g., separately com- 
pilable function, an entry in a tree chart 
or baseline diagram for the system at any 
point in time, or a shared section of data 
such as a COMMON block) . 
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computer time 


confidence 

level 


con«ti‘viints 


conatiTisints , 
space 


constraints, 

time 


control 

statements 


correction 

cosmetic 


create 

creation date 


cross- 

reference 


For batch usatje, this is the billable time 
for all runs. For interactive usa^e, it 
is the number of hours spent at a terminal. 

Percentage probability that a given number 
is correct: 100 percent means that the 

number is absolute certainty; 0 percent 
means that the numoer must be incorrect. 

Restrictions on resource availability (ex- 
ecution time, memory allocation) imposed 
by specifications. 

All restrictions caused by space problems. 
On the Component Summary Report form, list 
each restriction separately (e.g., maximum 
number of words that component may occupy 
at one time or maximum disk space avail- 
able during execution time or for program 
storage) . 

All restrictions caused by various machine 
and calendar time problems. On the Compo- 
nent Summary Report form, list each re- 
striction separately (e.g., maximum 
execution time for component to process 
and respond to some input condition or 
time to complete a component or milestone) . 

All statements that potentially alter the 
sequence of executed instructions (e.g., 
GOTO, IF, RETURN, or DO). 

A change made to correct an error. 

Changes in the source program that have 
little effect on the performance of pro- 
gram (e.g., correct comments, move code 
around as long as it does not alter the 
algorithm implemented, or change the name 
of 3 local variable) . 

The creation and recording of the idea. 

Date that the component was first named 
(e.g., date it first appeared on a tree 
chart) , 

List of the identifiers used by a program 
showing (by means of indices or statement 
numbers) which statements of the program 
define and reference those identifiers. 
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data base 
applications 


design 


design phase 


design reading 


development 

phase 


documentation 


dump 


end date 


English (or 

informal) 

specifications 


This category is to include components that 
retrieve, write to, or format information 
for a well-defined formatted bank of in- 
formation available to the system# The 
user must decide whether or not the data 
set is to be considered a data base. An 
example of an acceptable data base would 
be the ADL file, SLP file, or Geodetics 
file, whereas a sequential telemetry file 
or tape would not be. 

A description of what the system must do, 
its components, the interfaces among those 
components, and the system's interface (s) 
to the external environment. 

The creation and recording of the design, 
including discussion about strategy with 
peers. This phase does not include the 
development of any code at the programming 
language level. It does include the crea- 
tion of specifications for subcomponents 
of the current component. 

Visual inspection of the design by persons 
other than the creator of the design. 

The development and recording of code and 
inline comments based on the design. This 
phase includes the modification of code 
caused by design changes or errors found 
in testing. It does not include any time 
spent in entering the code into the com- 
puter. 

Written material, other than source code 
statements, that describes a system or any 
of its components. 

Record of the state of the memory space 
used by a program at some point in its 
execution. A dump may include all or part 
of the program's memory space (including 
registers) . 

Date that a project is scheduled to be 
completed. 

Specifications given as readable English 
text, as opposed to some formal notation. 
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error 


external 

environment 


formal spec- 
ifications 


function 


functional 

specifications 


hardest first 


HIPO (Hier- 
archical Input 
Process Output) 

implementation 


Integration 

test 


integration 
test, full 


Discrepancy between a specification and 
its implementation. The specification 
might be requirements, design specifica- 
tions, or coding specifications. 

Combination of hardware and software used 
to maintain and execute the software, in- 
cluding the computer on which the soft- 
ware executes, the operating system for 
that computer, support libraries, text 
editors, and compilers. 

Some specification technique based upon a 
strict set of rules for describing the 
specification and usually involving the 
use of an unambiguously defined notation 
(e.g., mathematical functions or formal 
PDL) . 

Mathemati^Tal notation used to specify the 
set of input, the set of output, and the 
relationship between input and output. 

Specification of a component as a set of 
functions defining the output for any in- 
put. The specification emphasizes what, 
the program is to do rather than how to do 
it. However, an algorithmic specification 
can be considered functional if it is not 
used to dictate the actual algorithm to be 
used. (See procedural specifications.) 

Design (or implementation) of the most 
difficult aspects of the system first. 

Graphical technique that defines each 
component by its transformation on its 
input data sets to its output data sets. 

Implementation of a program is either a 
machine-executable form of the program or 
a form of the program that can be auto- 
matically translated (e.g., by compiler or 
assembler) into machine-executable form. 

Test of several modules to check that 
the interfaces are defined correctly. 

Test of the entire system (i.e., top- 
level component) . 
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integration 
test# partial 

intended 
use of 


interface 


interactive 


iterative 

enhancement 


level 


level# lowest 


librarian 


I 

machine words 


manpower 


Test of any set of modules but not the 
entire system. 

Result of invoking a program or segment 
of a program# including the actions per- 
formed by that program when invoked. In- 
vocation may be by subroutine or function 
call or by a branch to a segment of code. 

Set of data passed between two or more 
programs or segments of programs and the 
assumptions made by each program about how 
the others operate. 

Use of a computer via a terminal in which 
each line of input 's immediately proc- 
essed by the computer. 

Design (or implementation) of successive 
versions# each producing a usable subset 
of the final product until the entire 
system is fully developed. 

Unit corresponding to some partitioning of 
the final product (e.g.# a single line of 
code# 10 lines of code# 25 lines of code# 
subroutine# or module) . If the system is 
hierarchically structured# each component 
is at a higher level than its subcompo- 
nents# and the system may be described as 
the highest level component (the component 
at level 1) # the component at level 2# or 
the lowest level component. 

Smallest unit identified by the activity 
(e.g.# code reading to the single state- 
ment# top-down design to the module level# 
or top-down design to level 3) . 

A clerk whose responsibilities include 
processing source statements but not writ- 
ing them# (e.g.# maintaining libraries# 
updating code# or producing tape backups) , 

Number of words in a main memory that a 
component occupies at one time. 

Sum# over the number of people, of the 
number of hours per person charged to the 
contract. 
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mathematical/ 

numerical 


maximum space 

mission date 
module test 
none used 

onboard 

processing 


optimization 


PDL 


This category is meant to be a more speci- 
fic category than the scientific class. 

It contains those components that reflect 
a specific algebraic expression or mathe- 
matical algorithm. Such components as a 
dot product routine or a numerical inte- 
grator are in this category. 

Total number of machine words that the 
system may occupy at one time. 

Date that system must be operational. 

Test of a single module. 

No explicit technique was specified to be 
used. 

All components that are built for the 
purpose of satisfying some onboard proc- 
essing need belor.3 to this class. Al- 
though the component may be built and 
tested on a computer that is not the real 
flight computer, it should be classified 
as onboard if the final destination is the 
OBC (onboard computer) . 

Changes in the source code to improve pro- 
gram performance (e.g., run faster or use 
less space) . Optimization changes are not 
error corrections; however, if a change is 
made to use less space to conform to the 
specified space constraint, then the term 
"error" applies. 

Program design language (often called 
pseudocode). Used in the design and cod- 
ing phases of a project, PDL is a language 
that contains a fixed set of control state 
ments and a formal or informal way of de- 
fining and operating on data structures. 
PDL code may or may not be machine- 
readable, and for this study it is not con 
sidered as documentation, but as an 
integral part of the finished source pro- 
gram. 
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procedural 

specifications 


proof 

technique 


range in mod- 
ule size 

read 


real-time 


requirements 


review 


scientific 


Specification of a component in some al- 
gorithmic manner (e.g.» using PDL or a 
flowchart). The specification says how 
the program is to work. (See functional 
specifications. ) 

Method for formally demonstrating that a 
piece of software performs according to 
Its specifications. Proof techniques usu- 
ally use some form of mathematical nota- 
tion to describe the result of executing a 
program. 

Number of source statements in a module# 
including comments. 

The reading by peers of the recordings of 
the current phase to look for errors# in- 
vent tests# and so on. 

This class includes components that are a 
direct function of events occurring at# or 
near# the current time. Typical compo- 
nents would be the Attitude Control 
Monitors. Since parts of most of the te- 
lemetry processors are required to process 
data as it is received# they too may be 
considered real-time components. 

System specification written by the user 
to define a system to a developer. The 
developer uses these specifications in 
designing# implementing# and testing the 
system. 

Formal meeting of several individuals for 
the purpose of explaining design (man- 
agement review) . Also includes the time 
spent in preparing for the review. All 
those attending a review should list the 
components discussed in their own Compo- 
nent Summary Report for that week. 

A component may be in this category if it 
is related to some mathematical algorithm# 
engineering problem# law of physics# or 
celestial mechanics problem. Most of the 
full systems developed will fall into this 
category, whereas the various pieces of 
modules may fall into some of the other 
classes . 
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segment 


shared items 


simulating 

constructs 


source 

instructions 

source 

statements 


specification 


specification, 

imprecise 


specification, 

precise 


Contiguous piece of code that it unnamed 
and, hence, cannot be referred to as a 
single entity in a program statement, k 
segment could be one or several lines of a 
subroutine, part of a data area, or an 
arbitrary contiguous section of memory. 

Data and programs, accessible by several 
components, such as COMMON blocks, ex- 
ternal files, and library subroutines. 

Statements that are used to simulate struc- 
tured control structures when the language 
to be used does not contain structured 
control structures. 

See source statements. 


All statements readable by and read by the 
compiler. This includes executable state- 
ments (e.g., assignment, IF, and GO TO) ; 
nonexecutable statements (e.g., DIMENSION, 
REAL, and END ) j and comments. 

Description of the input, output, and es- 
sential function (s) to be performed by a 
component of the system. The specifica- 
tion is produced by the organization that 
is to develop the system; that is, at the 
top level, it can be thought of as the 
contractor's Interpretation of the re- 
quirements. 

The input, output, and function of the com- 
ponent are loosely defined. Much of what 
is required is assumed rather than speci- 
fied. The specification relies heavily on 
programmer experience and verbal communi- 
cation to get an unambiguous interpreta- 
tion and a full understanding of what is 
needed. 

The input, output, and function of the com- 
ponent are well defined. There are under- 
lying assumptions not specified, but it is 
assumed that any programmer working on the 
project, with experience on a similar 
project, will understand these assump- 
tions. It is possible to arrive at an am- 
biguous interpretation or misunderstanding 
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ip«cif icatlonf 

pr«cist 

(Cont'd) 


spaclf icatlon, 
vary preciaa 


spacif ication- 
dcivan 


standards 


start date 


string process- 
ing 


structure- 

driven 


structure 
of data 


structured 

code 


of the specifications if the reader does 
not have enough experience with the prob- 
lem or does not obtain further verbal com- 
munication. 

Completely defined description of the 
inputs output f and function of a compo- 
nent. The implementer of a very precise 
specification need make few, if any, as- 
sumptions. It is almost impossible to 
arrive at an ambiguous interpretation or 
misunderstanding of the specifications. 

Using the specifications of the program to 
determine test data (e.g., test data is 
generated by examining the input/output 
requirements and specifications). 

Any specifications that refer to the 
method of development of the source pro- 
gram itself, and not to the problem to be 
implemented (e.g., using structured code, 
at most 100-lin'^ subroutines, or all names 
prefixed with subsystem name) . 

Date on which initial work on a project 
began. 

This includes components that perform op- 
erations on lists of characters. Norm- 
ally, this class is assumed to include 
functions of compilers, hash code string 
hook-up, and array comparisons. 

Using the structure of the program to de- 
termine test data (e.g., generating data 
to ensure that each branch of a program is 
executed at least once) . 

Organization of a composite data item con- 
sisting of several variables or other 
array items. Examples of such composite 
data items are arrays (both singly- and 
multiply-dimensioned), strings, complex 
variables and constants, records on a disk 
file (each record containing several 
words) , and multiple-word entries in a 
table. 

The language supports structured control 
structures (e.g., a FORTRAN preprocessor). 
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systems 


system size 


table handler 


telemetry/ 

tracking 


testing phase 


top-down 


trace 


type of soft- 
ware 


Sy system-related software# one includes 
any package designed to affect# modify# 
extend# or change the normal available 
processing procedure of the operating sys- 
tem. This could include such components 
as error tracing or extended I/O such as 
DA 10. 

Total number of machine words needed for 
all instructions generated on the project 
plus space for data# library routines# and 
other code. This is the total size of the 
system without using any overlay structure. 

Includes components that are specifically 
designed to generate or interpret informa- 
tion in a table format such as the Gener- 
alized Telemetry Processor. 

Includes all components that are spec- 
ifically required to interface (either 
read# write# or format) with telemetry or 
tracking data. 

Design of tests# testing strategies# and 
the running of such tests. This phase • ** 
does not include the writing of any code 
(even for debugging purposes) # which 
should be recorded under coding. 

Design (or implementation) of the system# 
starting with a single component# one 
level at a time# by expanding each compo- 
nent reference as an algorithm possibly 
calling other new components. 

Record of program execution showing the 
sequence of subroutine and function calls 
and# sometimes# the value of selected var- 
iables. Code used in producing a trace is 
automatically inserted into a program# 
usually by the compiler# sometimes by 
other support software. 

The four major classifications of most of 
the applicable software being developed 
are: scientific# business/financial# 

systems, and utility. These classifica- 
tions may be refined into the categories 
of: string processing, data base 

applications, real-time, and table 
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type of soft- 
ware 
(Cont *d) 


utility 


value of data 


walkthrough 


workaround 


handler. A further refinement includes 
the categories of: attitude/orbit # 

telemetry/tracking^ command/control, math- 
ematical r and numerical onboard. 

Any component that is generated to satisfy 
some general support function required by 
other applications software may be con- 
sidered a utility. This class of compo- 
nents usually contains software that does 
not fit into any of the other three cate- 
gories. Although components can fall into 
two of the primary categories (e.g.i 
scientific and utility), it will be easier 
to use only the more descriptive of the 
categories (e.g., vector cross-product-- 
scientific; data unpacking--utillty) . 

The number and kind of number (e.g., in- 
teger, floating-point, or ASCII-encoded 
character) stored in a local variable or 
data area, parameter, common variable, or 
system-wide data item. 

Formal meeting sessions for the review of 
source code and design by the various mem- 
bers of the project for technical rather 
than management purposes. The purpose is 
for error detection and not correction. 

The method used to counteract the effects 
of an error in a program when the cause of 
the error and, consequently, the location 
of the statements containing the error is 
not known or is inaccessible (e.g., a com- 
piler error) . 
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APPENDIX C - ABBREVIATIONS 


The following are explanations of abbreviations used 
throughout this document. 


ACC 

ATM 

CIP 

CMT 

CRP 

CSC 

CSP 

CSR 

DBl: 

DBAM 

DEC 

DIR 

ENC 

GPS 

GSPC 

HDR 

HIPO 

HIS 

JCL 

PDL 

RAF 

RJE 

RJP 

RMS 

RMS I AC 
RSP 

RSX-llM 

SAP 

SEP 

TSO 


Accounting Information File 

Attitude Maintenance Change Report File 

Component Information File 

Comment File 

Change Report Form 

Computer Sciences Corporation 

Component Summary Form 

Component Status Report 

Disk DBl 

Data Base Maintenance Software 
Digital Equipment Corporation 
Subjective Evaluations Directory Pile 
Encoding Dictionary 
General Project Summary 
Goddard space Flight Center 
Phase Dates File 

Hierarchical Input Processing Output 

Growth History File 

Job Control Language 

Program Design Language 

Run Analysis Form 

Remote Job Entry 

Remote Job Processing 

Record Management System 

RMS Indexed Access routines 

Resource Summary Form 

Current PDP-11/70 Operating System 

FORTRAN Source Analyzer Program 

Subjective Evaluations File 

Timesharing Option (IBM) 
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UIC 

UM 

YYMMDD 

(n,m) 


User Identification Code 
University of Maryland 

Yoar*Year-Month-Month-Day-Day date format. 

For example, 810704 is July 4, 1981. 

User Identification Code. For example, [204,1] 
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APPENDIX D - USER IDENTIFICATION CODE (UIC) LAYOUT 


This appendix lists the organization of all production soft- 
ware located under the User Identification Code (UIC) of 204 
on disk DBl. 

1. (204,1]--A1I data base files. 

2. (204,2) — Not used. 

3. [204, 3] --Indirect command files for DBAM or tape 
delivery, plus temporary intermediate files used by 
DBAM. 

4. [204, 4) --Indirect files for reports and other 
utility programs. 

5. [204,5] — All task images. Help files associated 
with each task image. 

6. [204,6] — Source code and object modules for all 
task images except DBAM. Command and overlay files 
to create task images. Fixed input data files to 
programs. 

7. [204, 7) --Utility source covIe and object modules 
used by several programs (e.g., generalized open 
and read routines) . 

8. [ 204, 10] --DATATRIEVE record and domain-definition 
indirect files. 

9. [204, 11] --Prof ile reports and all reports produced. 

10. [204,12] --Tape backup command files. 

11. [204, 15] --DBAM source code and object modules, plus 
task generation command files and overlay files. 
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